NilsOF

Noe sånt tenker jeg å bruke på en veranda med flatt tak. Problemet med verandaen er at snøen hoper seg opp ved normalt vintervær. Når temperaturen stiger (og kanskje regner) så samler det seg vann ved veggen. Ikke bra.

@GeirAGviktig å beholde perspektiv på saker og ting, ja Å sette inn en ESP8266 var forøvrig smertefritt, jeg har så langt ikke tuklet med selve koden i ESPen. Dvs. smertefritt om man klarer å lodde på 4 ledninger på riktig plass og også manøvrere i Arduino-programmet. Det som virkelig var utfordrende var å integrere mqqt i Openhab. Vanskelighetsgraden med å integrere mqtt vil ganske sikkert variere fra system til system. Skrev litt om ESP8266 og hvilke deler man trenger hær.: https://www.hjemmeautomasjon.no/forums/topic/2887-mitsubishi-varmepumpe-på-esp8266-og-mqtt/?do=findComment&comment=64861 Jeg nyter nå toveis kommunikasjon med varmepumpa og det var målet. Litt finpussing gjenstår.

Virker som alt er sky-løsninger, selv om produsent sier "app". Har kommet til at det er tull å betale ekstra for propetiær løsning med kastrerte muligheter. Jeg har begynt å se etter ovner som enkelt og sikkert kan modifiseres med implantat..

Godt poeng. Jeg bruker maddammen som instrument for opplevd temperatur. Ganske verbost verktøy, men veldig unøyaktig. ?

Jeg bruker en laser-temp-måler fra Biltema nå da jeg mikker med temperaturer. Ikke veldig nøyaktig, men den er effektiv til å finne hvor/hvordan temperaturene varierer i et rom på en rask måte. Nesten er helt nødvendig verktøy for meg iallefall. Det er vanskelig å styre mot noe man ikke vet, men har en målt faktisk temp er det mye enklere å definere tilltak

For ikke å dra tråden fullstendig ut av "toepick" ? For å starte med hjemmeautomasjon må man bare velge ett system. Dess mere research som legges bak valget, dess lengre vil valget være ett bra valg. Ikke forvent evig levetid på systemet. Sånn fungerer ikke ting i denne verdenen. Shit happens, tingenes tilstand tar en krokvei, maintainere skaffer skaffer seg et liv, selskaper blir solgt eller går dukken osv.. Det er lurt å være såpass smart at man skjønner at det ikke går å ikke kan outsmarte det uventede.

Tja, sett i verdenssamenheng er det ikke mye til disrupsjon. Vil heller betegne Tesla som en frisk pust som er blitt lagt merke til. Det er verdt en øvelse i filosofering om hvordan vi vil se på dagens Tesla-modeller om fem år. Skrot og et miljøproblem eller noe som kan brukes enda 15 år? Muligens er alle samen transportert til Afrika fordi det er mulig å resilkurere lithium fra ett åpent bål eller noe slikt..

Dette er ikke en guide, men mere ett pågående arbeide. Håpet er at jeg kan få tips om forbedringer. Forhåpentligvis vil det også hjelpe andre til relativt raskt å få ett oppsett å bygge videre på. Å sømme samen småbiter fra internet til det jeg poster hær var en ganske lang og frustrerende ørkenvandring. broker.things: mqtt:broker:mosquittoBroker "Mosquitto mqtt broker" [ host="192.168.1.20", secure=false ] mqtt.things: Thing mqtt:topic:varmepumpe "Varmepumpe" (mqtt:broker:mosquittoBroker) @"Stue" { Channels: Type switch : power "varmepumpePower" [ stateTopic="varmepumpe", transformationPattern= "JSONPATH:$.power", commandTopic="varmepumpe/set", formatBeforePublish="{\"power\" : \"%s\"}", on="ON", off="OFF" ] Type string : mode "varmepumpeMode" [ stateTopic="varmepumpe", transformationPattern= "JSONPATH:$.mode", commandTopic="varmepumpe/set", formatBeforePublish="{\"mode\" : \"%s\"}", allowedStates="HEAT,DRY,COOL,FAN,AUTO" ] Type number : temperature "VarmepumpeTemp" [ stateTopic="varmepumpe", transformationPattern= "JSONPATH:$.temperature", commandTopic="varmepumpe/set", formatBeforePublish="{\"temperature\" : \"%s\"}" ] Type string : fan "Varmepumpe vifte" [ stateTopic="varmepumpe", transformationPattern= "JSONPATH:$.fan", commandTopic="varmepumpe/set", formatBeforePublish="{\"fan\" : \"%s\"}", allowedStates="AUTO,QUIET,1,2,3,4" ] Type string : vane "Varmepumpe Vane" [ stateTopic="varmepumpe", transformationPattern= "JSONPATH:$.vane", commandTopic="varmepumpe/set", formatBeforePublish="{\"vane\" : \"%s\"}", allowedStates="AUTO,1,2,3,4,5,SWING" ] //Type string : wvane "Varmepumpe WideVane" [ // stateTopic="varmepumpe", transformationPattern= "JSONPATH:$.wideVane", // commandTopic="varmepumpe/set", formatBeforePublish="{\"wideVane\" : \"%s\"}", // allowedStates="<<,<,|,>,>>,<>,SWING" //] Type switch : operating "Varmepumpa jobber" [ stateTopic="varmepumpe/status", transformationPattern= "JSONPATH:$.operating", on="true", off="false" ] Type number : roomTemperature "VarmepumpeRomTemp" [ stateTopic="varmepumpe/status", transformationPattern= "JSONPATH:$.roomTemperature" ] } Grunnen til at broker.things er splittet fra mqtt.things er at en bug i Openhab krever full restart av openhab -servicen når fila med brokeroppsettet blir editert. Dette var en alvorlig snubblefelle som stjal mye tid. Jeg kommenterte ut widevane i mqtt.things. Ett eller annet med dette gjør at openhab bomber fra seg en haug av feilmeldinger. Noe er også litt rart med hele vane-oppsettet. Tror det er noe i programmet i ESPen som ikke er helt med på utstyret pumpa mi har. varmepumpe.items: Switch varmepumpePower "Varmepumpe Power" {channel= "mqtt:topic:varmepumpe:power"} String varmepumpeMode "Varmpumpe Mode" {channel= "mqtt:topic:varmepumpe:mode"} Number varmepumpeTemp "Varmepumpe Temp" {channel= "mqtt:topic:varmepumpe:temperature"} String varmepumpeFan "Varmepumpe Vifte" {channel= "mqtt:topic:varmepumpe:fan"} String varmepumpeVane "Varmepumpe Vane" {channel= "mqtt:topic:varmepumpe:vane"} String varmepumpeWideVane "Varmepumpe WideVane" {channel= "mqtt:topic:varmepumpe:wvane"} Switch varemepumpeOperating "Varmepumpa jobber" {channel= "mqtt:topic:varmepumpe:operating"} Number varmepumpeRomTemp "Varmepumpe RomTemp" {channel= "mqtt:topic:varmepumpe:roomTemperature"} Brukte en Adafruit Huzza breakout med programmvare herfra https://github.com/SwiCago/HeatPump HeatPump-master/examples/mitsubishi_heatpump_mqtt_esp8266_esp32 Jeg skrev mere om ESPen hær:

Alt jeg trengte bestillte jeg fra elfa: Art.-nr. PDN 300-91-186 2471 HUZZAH https://www.elfadistrelec.no/no/esp8266-breakout-enhet-esp8266-wifi-adafruit-2471-huzzah/p/30091186 300-21-706 PAP-05V-S https://www.elfadistrelec.no/no/krympehus-poles-jst-pap-05v/p/30021706 143-52-231 K120121021 https://www.elfadistrelec.no/no/forkrympet-ledning-df11-hunn-df11-hunn-500mm-24awg-stig-wahlstroem-elektronik-k120121021/p/14352231 143-52-235 K120121025 https://www.elfadistrelec.no/no/forkrympet-ledning-df11-hunn-df11-hunn-500mm-24awg-stig-wahlstroem-elektronik-k120121025/p/14352235 Liftet ett bilde fra internet som viser hvilken pin på kontakt som skal til rx tx 5v gnd. Dette er IKKE mitt, husker ikke hvor det kommer fra. Bildet av kretskortet i min Mitsupumpe.

Jeg poster litt info i denne tråden i håp om at det blir sett: Har akkurat fått implantert inn en ESP8266 i min Kaiteki 6,6 KW MSZ-LN35(ånoe) Mitsuen har ett medfølgende WiFi-adapter. Dette er plugget inn på kretskortet på en annen kontakt enn cn105. (tok ett bilde som jeg ikke finner i akkurat nå..mener det sto prog eller noe slikt på den pluggen) Oscilloscopet mitt er pakket ned, så jeg tok sjansen på å plugge inn ESPen inn i cn105 uten å måle noe. Det orginale WiFi-adapteret er også fortsatt koblet til på pluggen sin. Jeg stusset stort over anbefalingen om å bruke to 10k motstander som pullup fra 5volt på henholdsvis Rx og Tx. Kan ikke skjønne annet enn at dette er feil og at det muligens over tid kan skade ESPen! Jeg valgte å bruke en Adafruit Huzza Breakout pga. at det finnes pålitelig dokumentasjon fra Adafruit. Og det viste seg at Adafruit har beskyttet rx-inngangen med en diode. Et meget enkelt og effektivt ninjatriks. Slik: tx (fra Mitsupumpa) ----|<--- rx på ESPen ESP8266 har også interne pullup motstander til 3.3volt. Det er litt uklart for meg om disse pullupene er slått på eller ikke, men jeg tror det. Huzzaen virker uten noe behov for å sette på ekstern pullup. Den har også innebygd 5volt til 3.3volt regulator. Altså ingen ekstra remedier er nødvendig. For å konkludere: IKKE sett på pullup motstander til 5volt! Beskytt rx med diode som Adafruit gjør. Adafruit oppgir at de bruker 1n4148 Om man må ha pullup på tx, så forankre den til 3.3volt (ikke 5volt). jeg tok i bruk "mitsubishi_heatpump_mqtt_esp8266_esp32" fra github Så langt uten noen endringer i kode, foruten SSID og wifipassord, samt peking til mqtt-brokeren. Jeg slo også på OTA, men er litt usikker på om jeg må manuelt resette ESPen etter oppgradering.

hehe, brukervennlig kommer veldig an på hvem brukeren er. Jeg ville aldri anbefalt OpenHab til bestef.. ..hei, vent nå litt.. Jeg er jo i den alderen selv.. (at mine unger ikke har knødd seg til å lage avkomm enda er ikke noe jeg kan styre) Så, ja, jeg kan helt klart anbefale OpenHab til meg selv. ?

Jeg befinner meg nesten på scratch med hjemmeautomasjon. Jeg trodde jeg var godt i gang når jeg hadde fått dimmere og releer til å varme og vifter til å spille etter sensorer. Betegner meg som litt små-naiv da jeg trodde dette skal gå snorbent fremover. Et eksempel: kjøpte jeg meg en Mitsubishi varmepumpe. Det medfølgende wifi-adapteret er egentlig verdiløst da det krever en skyløsning. Og poof, ESP8266 og mqtt kommer inn i livet mitt som nye teknologier. ESP-chippene har jeg lenge vært i startgropa på og har dillet med Arduino før. mqtt ante jeg ikke at eksisterte for en måned siden. Nå har jeg en tendens til å gå mye lengre ned i materien en folk flest, men likevel er hjemmeautomasjon i dag et sammensurrium av forskjellige teknologier. Man må sette seg inn i sakene skal man få et godt resultat ut på andre siden. Det er i detaljene smådjevlene gjemmer seg. For å ikke ende opp med et system som best egner seg som stjernen i en episode av "Åndenes makt" med påfølgende gammeldags katolsk djevelutdrivelse så bør smådjevlene taes før de vokser til og begynner å formere seg. Det er bare å brette opp ermene, skaffe seg kunnskap og dure på. Knepp smådjevlene mot pottekanten før de er tørre. Av og til lurer jeg på hva "vanlige folk" driver med. Til nå har jeg ikke klart å definere hva "vanlige folk" er for noe. Kanskje ett kriterie er "de som ikke diller med hjemmeautomasjon". Når jeg ser inn i krystallkulen så ser jeg at jeg mer eller mindre må starte på nytt. Men det er tåkete og full snøstorm i kula mi, litt vanskelig å trekke ut når og hvordan. ?

For å nyttegjøre seg hvert enkelt vlan så må PCen ha som minimum en IP-adresse for hvert enkelt vlan. Dvs.helt nødvendig for å sende svar på forespørsler tilbake til det som spørr.

Jo. Det er riktig at untagged ikke har en header, og det trenges heller ikke. samtidig må headerene (etterfulgt av nettverkspakkene for hver enkelt vlan) på ett eller annet vis sendes over kabelen. Dette gjøres ved at hver enkelt vlan- nettverkspakke puttes inn bak vlanheaderen og sendes over kabelen som hvilket som helst annen nettverkspakke. Det finnes switcher som er istand til å videreformidle taggede vlan selv om de selv ikke støtter vlan. Grunnen til at dette virker er at disse switchene sender den innpakkede vlan trafikken videre lykkelig uvitende om innholdet. hm, knotete forklart, og jeg finner ingen illustrasjon nå i farten.

Jepp, sånn er det. Denne headeren er plassert i det utaggede nettet som ligger i bunnen når det går ut fra boksen.

Har hatt flere viltkamera. Problemet er å finne ett godt et. Jeg har ikke løst den nøtta. Prisene kan også være i hytt og pine, og er en upålitelig pekepinn. Om du vil fange opp hjortedyr uforstyrret så gå for ett med " black ir". hjort og rådyr vil sky ir i bølgelengder de kan se. Elgen ser det samme men bryr seg ikke om det. Er man konge så er man konge.

Må tillegge at begrepet bridging i dag mest er i bruk inne i software, som feks. Linux. Når man først har det inne i software så kan man også legge på brannmurregler eller aksesslister som det heter på Cisco-språk.

@ZoRaCJeppjepp, vi er på samme siden. Bridging er i praksis det samme som switching ? Jeg ville bare ha enda mere fram i lyset hvorfor det er så viktig å skille funksjon fra boks.

Du tar ikke feil, men man kan koble samen to vlan med samme subnett ved hjelp av "bridiging". Dette må konfigureres spesifikt i de fleste tilfeller. For å forårsake enda mere forvirring så gjør noen bokser dette automatisk, som eksempelet jeg nevnte over med de billige "internet-routerne".

Alle vlan må ha en ren port å "ligge i" når de taes ut av en boks over en patcheport. Man kan gjerne referere til denne rene porten som untagged.

Er det eksempelet fra Ubiquiti du lenket til over du refererer til? Freste fort igjennom det. De nevner vlan 100 på to switcher dær de to vlanene på hver sin switch er helt urelatert til hverandre. I praksis er dette rett og slett farlig å gjøre. Altfor mye kan missforståes . En glipp og vipps så har man patchet samen to helt urelaterte nettverk. En switch ser bare taggen (dvs. nummeret) på vlanet. Den vet ikke noenting om hva som er inni vlanet. Eneste grunnen til å gjenbruke vlan-nummer jeg kan tenke meg som er ok er om man vil ha likt oppsett på flere geografiske lokasjoner. Har enda tilgode å plukke på ett Ciscoprodukt som ikke støtter vlan. Antallet mulige vlan pr. interface har variert.

Det finnes faktisk bokser bokser som fungerer som @ATWindsor beskriver. Og det er en vanvittig mengde av dem. Minst en pr hustand. Felles for de alle er at absolutt alt er skrapet ned til minimum for å holde produksjons-prisen nede. Kineserene er veldig flinke, om de kan spare ett riskorn så gjør de det. SoCen ( system on chip) har flere nettverksinterface, hvorav en går til wifi, og en går til en swtich-brikke. Vel og bra og ren konstruksjon, hadde produsentene bare holdt seg til dette.. Er der flere nett-intefacer på SoCen så er disse kanskje dratt ut bak også. Gjerne dratt ut bak samen med portene fra switchen. Og blandet innimellom portene fra switchen. Man skal jo lage et billig produkt og kretskort er dyrt.. Desse flere porter bak dess bedre salgbart. For å løse portkaoset og for å kunne merke en av portene som utside av NAT så taes portene bak inn til interfacet på SoCen som hvert sitt vlan. ( og det kan bli riktig hårete, alt etter som switce-brikken er laget). Stakkarene som skal sømme samen dette kaoset til et produkt som er "bra nok" må da benytte seg av bridging mellom vlanene. Linux gjør jo dette gratis. Boksene man ser i hylla på butikken er det mest gjennomtenkte med hele produktet. Det står router i store glossy bokstaver.

Siterer og korrigerer meg selv. Et vlan er synonymt med ett helt gammeldags nettverk med switcher. Man sparer med andre ord ikke bare noen patchekabler og porter men også switch(er).

Mnja, et vlan kan best samenlignes med en virituel patchekabel. Dhcp er et annet stygt dyr i skogen. Jeg vet ikke helt om jeg har lyst til å gå dit i kveld ? Andre stygge dyr i skogen er switcher og bridger. Egentlig samme dyret med forskjellig navn. De fleste routerbokser støtter disse også.. Edit: hjernen er oppbrukt for idag, jeg glemte det store stygge NATte dyret.

@Floyd Om du mener over to forskjellige vlan på samme netverksinterface vs. bruke to netverksinterfacer uten vlan, så nei. Ulempe: Man må ha nok båndbredde for begge vlanene i det taggede interfacet. Fordeler: Man sparer en port pr. ekstra vlan med det taggede interfacet og også på switch. En patchekabel er også mere ryddig.