All aktivitet

En liten oppdatering: Jeg har nå flere zigbee enheter, og flyttet over noen av lysene mine fra hue til HomeAssistant sitt zigbee nett på kanal 20. Dvs. at jeg nå har 29 lys + 7 andre batteri-enheter på hue sitt zigbee nett (kanal 25) Og Home Assistant sitt zigbee nett på kanal 20 har tilsammen 29 enheter inkl. noen batterienheter. Dette fungerer foreløpig smertefritt. Noen hue-lys kommer nok til å bli flyttet over til det andre nettet, bla.a. for å få bedre dekning i garasjen, men det fungerer også bra i dag.

«Graset er ikke grønnere…» 14 år med Homeseer avsluttes nu, det har vært en sann glede, mye frustrasjon og enda mer velvilje fra andre som har vært tålmodige med en som tror manualer er farlige. Nå har jeg konvertert til «enklere» system, mer tilpasset en «enkel kar». Liker bedre wizarder og 1 firma - fremfor 3.-part plug-ins for VIKTIGE ting som lys. PS: Må bare kjøre en mnd. tid før jeg kan lufte interesse for lisens, NUC osv.

Egentlig ikke. Om morgenen foretrekker kona å trykke på en Zigbee knapp i garasjen som åpner og lukker porten med en liten forsinkelse. Akkurat nok til å rygge ut bilen. Og på vei hjem "tæpper" hun mobilen på en NFC brikke som er skjult under dashbord. Garasjens fjernkontroll blir ikke brukt.

Sant nok. Er vel kanskje bare styrken på magnetfeltet som betyr noe uanskvett? Men over til neste problem, som heller ikke burde vært noen overraskelse: Det viser seg at løsningen påvirker rekkevidden for de ordinære 433 MHz fjernkontrollene merkbart. Det gir veldig dårlig waf når vi er vant med å åpne porten fra gata nedenfor og bare suse rett inn i åpen garasje. Eneste fornuftige teori er rett og slett interferens. Burde nok ikke plassert en radio så nær fjernkontroll-antenne og styring. Dumt. Så mye for den "elegante" løsningen med ADSL-dongle. Blir nok pent nødt til å bruke litt lenger kabel her. Det er jo en smal sak å fikse Hjelper nada at porten kan styres fra mobifonen eller fullautomatiseres hvis den ikke "virker som før". Regner med dere vet hvordan det er 😉

En stakkarslig Zigbee sensor vil vel fungerer like bra her som alle andre steder, så lenge magneten aktiverer reed-kontakten som disse har.

3D-printer er fint til slikt... Lage en tilpasset brakett...

Lærer stadig ting jeg burde ha visst fra før. Kan det være alderen? Monterte en (hadde ikke flere) av magnetbryterne i dag. Trodde jeg hadde vært på den sikre siden mht påkrevd avstand. Men tenkte ikke på effekten av stålskinner. Rekkevidden ble drastisk lavere når jeg plasserte bryteren der jeg hadde tenkt. Ser ikke noen gode alternativer heller. Ønsker ikke å lage noen voldsomme braketter. Heldigvis ser det ut til at det akkurat gikk med denne plasseringen. Avstand mellom magnet og bryter er vel 1 - 1,5 cm. De funker med mer enn det doble i fritt rom. Men altså ikke når bryteren er limt til en stålskinne Hvordan monterer egentlig folk flest disse tingene? Ser med gru på hvordan dette skulle fungert med et stakkarslig batteridrevet zigbee-sensor f.eks.

Anbefaler ikke piller.. Tradisjonelt hjul er bedre IMO. MicroMatic har zigbee piller.

Akkurat overtatt leilighet med masse fancy lysbrytere, som bruker fase-avsnitt til taklysene (mye OneA etc), ingen smarts utover manuell dimming ved å holde inne. Kanppene er av typen som spretter tilbake i posisjon så er godt utgangspunkt for automatisering med en pille håper jeg. Har brukt Hue i gammel leilighet, men her er lysene fancy greier som er satt, så tenker å kjøpe en Homey Pro og sette inn Zigbee piller. Noen anbefalte Plejd men det virker litt mer lukket og bruker Bluetooth 🙈 Hva er de gode alternativene å legge bak dimmebryterne? Har brytere med 1, 2 og 3 knapper. Er greit oppegående teknisk, men det må likevel være noensom ikke krever for mye vedlikehold og fikling. Tålmodighet ved ustabilitet vil være begrenset hos bedre halvdel 🤪 Hvilke piller anbefaler dere og hvorfor?

Da endte jeg også med en Shelly Plus Uni, selv om planen egentlig var å få brukt opp en Shelly Uni. Ref Dermed er garasjeporten (nesten) automatisert. Neida, ikke så spennende. Eier ikke fantasi. Må bare få montert et par magnetbrytere. Det er hensikten med den ledige RJ45-porten. Der har jeg to ganger jord + inputene til Plus Uni plassert på pinne 1,2 og 7,8. Tok litt tid før jeg skjønte at Plus skal ha inngangene ned i stedet for opp. Lese dokumentasjon? Det er for pingler. Trodde jeg bare kunne bytte ut Unien uten å koble om på innsiden av RJ45-skjøten. Men det gikk jo ikke. Jaja, er vel lurere slik antar jeg. Mindre sjanse for at en fiklepetter som meg dreper en inngang med feil spenning. Den hvite RJ45-kontakten er bare en gjennomkobling av kabelen til motorstyringen. Hadde en kablet bryter i inngang 1 og vil beholde den. Koblingen til motorstyringen er en nedfilt telefonplugg. Dette er en slik dongle med 6P4C plugg og 8P4C kontakt som pleide å følge med ADSL-rutere. Burde selvsagt hatt en ekte 4P4C plugg, men fant ingen. Og hadde jo egentlig tenkt å klare meg uten å kjøpe noe til dette prosjektet. For de som lurer: Port 2 på motorstyringen fungerer bare som stopp og lukk. Port 1 fungerer som åpne, stopp og lukk. Kunne selvsagt koblet det andre releet til port 2. Men så ikke helt hensikten (forutsatt at jeg får på plass sensorene som forteller meg om porten er lukket). Og for de som lurer på pinouten på disse Crawford/Normstahl motorene (det gjorde ihvertfall jeg) så er den jord impulsbryter impulsbryter +35V Jeg fant et dokument som påstod at bryteren skulle koble pinne 3 til jord, men det funket ikke. Det er pinne 2 og 3 som kortsluttes for å trigge start/stopp. Dette gjelder begge impuls-inngangene. Jeg gjetter på at det er nokså likt på de to andre inngangene også, med tilpasninger som at pinne 2 og 3 er RX og TX (eller motsatt?) for fotocellene på inngang 3. Var litt overrasket over at spenningen var såpass høy. Dokumentasjon jeg har funnet sa 24V. Men tar nå uansett sjansen på at Plus Unien også takler det, selv om det er slightly utenfor spec. Ikke all verdens mest avanserte case design, men er fornøyd med hullet jeg borret ved dioden. Etter å ha drept Unien fant jeg det praktisk med et visuelt livstegn 🙂

Så var det på tide med noen tabber igjen. Har hatt en Shelly Uni liggende i en evighet etter et impulskjøp uten mål og mening. Men endelig tok jeg mot til meg og prøvde å bygge den inn i noe nyttig. Var passelig ferdig og skulle bare "teste" litt. Kanskje litt vel slumsete. Mistenker at jeg sendte 9V (som var strømforsyningen jeg testet med) inn på sensor-input. Den falt ihvertfall brått av nett og kom aldri tilbake igjen. Og LEDen lyser nå konstant, også ved boot. Dårlig tegn. Koblet meg på serieporten og ble litt lettet over at det var action der. Kunne fint lese mac-adresse osv, og tilsynelatende også flash. Men det jeg leste ut fra flash er for det meste bare 0, med en og annen 1 bit i ny og ne. Absolutt ikke riktig. Og alle forsøk på å skrive noe annet feiler sjekksum-verifisering. Og booter selvsagt ikke. Etter noen forsøk med flash erase og write ble den faktisk enda sykere. Nå kommer den seg ikke vellykket gjennom en read_mac engang (og joda, jeg har prøvd med et par forskjellige USB TTL moduler, samt power fra USB eller fra intern forsyning. ingen forskjell): $ esptool.py -p /dev/ttyUSB3 read_mac esptool.py v3.3.1 Serial port /dev/ttyUSB3 Connecting.... Detecting chip type... Unsupported detection protocol, switching and trying again... Connecting... Detecting chip type... ESP8266 Chip is ESP8266EX Features: WiFi Crystal is 26MHz MAC: 34:94:54:7a:dd:ec Uploading stub... Running stub... Stub running... Traceback (most recent call last): File "/usr/local/bin/esptool.py", line 5399, in <module> _main() File "/usr/local/bin/esptool.py", line 5392, in _main main() File "/usr/local/bin/esptool.py", line 4824, in main operation_func(esp, args) File "/usr/local/bin/esptool.py", line 4222, in read_mac mac = esp.read_mac() ^^^^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 1404, in read_mac mac0 = self.read_reg(self.ESP_OTP_MAC0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 708, in read_reg val, data = self.command(self.ESP_READ_REG, struct.pack('<I', addr), timeout=timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 468, in command p = self.read() ^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 413, in read return next(self._slip_reader) ^^^^^^^^^^^^^^^^^^^^^^^ StopIteration Jaja. Bortsett fra noen timer bortkastet på et prosjekt jeg ikke engang fikk testet ordenlig så er det jo bare mindre skapfyll. Problemet er at jeg kommer vel til å kjøpe en Plus Uni nå som jeg har et prosjekt å plugge den inn i. Og da er det bare tap. Lærte jeg noe? Håper det. Ikke brekk ut flere pinner enn du strengt tatt har tenkt å bruke i et prosjekt, fordi det kan være "kjekt å ha"

Kikket litt nøyere etter i z2m, og dimmerne annonserer da virkelig støtte for OTA-clusteret så vidt jeg kan se. Ser også at z2m har fått 0x36 versjonen som et "genOta" attributt (eneste dingsene jeg har med det, uten at jeg aner noe om hvorfor/hvordan): "genOta": { "attributes": { "currentFileVersion": 54 } } Veldig usikker på hvordan vi bør tolke den type info fra kundeservice. Mistenker at dimmerne støtter OTA helt fint, men at infrastrukturen med en firmware-server mangler.

Som en tommelfingerregel oppgraderer jeg aldri til en .0, de fleste alvorlige bugsene bruker å være fikset i .1 (Og les alltid release notes og bugfixes) Har aldri vært plaget med at z2m har vært ustabilt.

Selv så bruker jeg disse (433MHz) i frysere og kjøleskap. Du kan maksimalt ha 8 stykk. De klarer helt greit å sende fra fryser og kjøleskap til RfLink/RfxTrx https://www.kjell.com/no/produkter/smarte-hjem/smarte-sensorer/smarte-temperatursensor/telldus-termometer-og-hygrometer-for-tellstick-3-pk.-p51428 Jeg antar at dette er billigere enn det endel leverandører skal ha for å gjøre frys og kjøl "smart". Og ofte er det skyløsninger som må hackes for å få det inn.

Takk - jeg tror dette er løsningen jeg må se mer på, mer bevisst bruk av tilstander som triggere.

Bummer. Det høres jo unødvendig herkete ut. Og dette hadde de ingen planer om å gjøre noe med? Jeg er litt usikker på om jeg gidder klage hvis det er slik at de må byttes fysisk for å fikse firmware... Ser at mine rapporterer "swBuildId": "2.9.2_r54" (i følge databasen til zigbee2mqtt). Klarer ikke helt matche 0x00000036 til noe. Hvor sjekker jeg denne versjonskoden? Ah, 0x36 = 54. Det er kanskje "_r54" da?

Jeg lagde all varmestyring i pyscript som en app. I ettertid har jeg flyttet det meste over til automasjoner, men varmestyringen er såpass komplisert at den er fortsatt i pyscript som en app. Som du ser av konfigurasjonen nedenfor, er det en lang rekke med innganger for å avgjøre om en climate skal være i "borte", "øko" eller "komfort". Tilsvarende er det for alle andre rom og gulv. Når det gjelder VVB så har jeg en automasjon som tester på tilstander. Jeg bruker template sensorer til å sette tilstander som jeg tester eller trigger på i automasjoner. Lys og gardiner er i samme situasjon som varme, jeg har app'er i pyscript som håndterer det. Det du har planlagt med å deaktivere og aktivere automasjoner etter behov, gjør jeg ikke. Alle mine automasjoner er aktive og de har fornuftige triggere og betingelser basert på at de er aktive hele tiden. Mine tilstander er hjemme, borte, besøk og ferie. Automasjoner og app'er i pyscript har tester på disse der det er aktuelt. varme: - output: climate.stue_og_kjokken delay: 1 delay_on: 0 away_mode: away prisforhold: sensor.peak_forhold prisforholdgrense: 106 nattsenkning_h: 3 nattsenkning_l: 1 default_mode: eco inputs: input1: entity_id: sensor.regulator_energy_usage below: 40 mode: away processing: stop input2: entity_id: binary_sensor.vindu_2_etg_a state: "on" mode: away processing: stop input3: entity_id: binary_sensor.vindu_2_etg_b state: "on" mode: away processing: stop input7: entity_id: input_boolean.oppvarming_med_gass_eller_ved state: "on" mode: away processing: stop input8: entity_id: sensor.pricelevel state: "EXTREMELY_EXPENSIVE" mode: away processing: stop input9: entity_id: input_select.sett_opp_temp_ved_besok state: "Overnattingsbesøk" mode: add input10: entity_id: input_select.sett_opp_temp_ved_besok state: "Dagsbesøk" mode: add input11: entity_id: binary_sensor.noen_er_hjemme state: "on" mode: add input12: entity_id: input_boolean.sleeptime state: "on" mode: eco input13: entity_id: binary_sensor.soonsleeptime state: "on" mode: eco input14: entity_id: binary_sensor.preheat_day state: "on" mode: add input15: entity_id: binary_sensor.preheat_night_weekend state: "on" mode: add input19: entity_id: sensor.pricelevel state: "VERY_EXPENSIVE" mode: dec input_heat_limit: entity_id: binary_sensor.heatlimit_morning state: "on" mode: eco input20: entity_id: binary_sensor.preheat_night_home_office state: "on" mode: add input_ferie1: entity_id: binary_sensor.soon_travelling state: "on" mode: away input_ferie2: entity_id: calendar.ferie state: "on" mode: away input_ferie3: entity_id: binary_sensor.soon_not_travelling_room state: "on" mode: comfort input_soon_home: entity_id: input_boolean.soonhome state: "on" mode: add

Jeg gjør det samme som du. Viktigst med et stabilt system.

Hei, Samme her. Byttet til ny dimmer forrige helg. Foreløpig ser det veldig bra ut, men tenkte å drøye en liten uke til før jeg oppdaterte forumet - for å være helt sikker. 🙂 -MariusL

Hei! Jeg har en HA installasjon som, basert på ulike statuser, aktiverer / deaktivere ulike automasjoner og slår på/av ulike varslinger og releer. Strever litt med å finne en god metode for å sette opp dette, som gir meg god oversikt og sikre at det er enkelt å vedlikeholde. Et alternativ er å legge all logikk inn i Automations knyttet opp til drop-down list i "Helper", men det gjør hver automasjon unødvendig komplisert. Behov: - Aktivere / deaktivere automasjoner basert på statuser - Når en status endres skal ulike brytere aktiveres / deaktiveres - Få god oversikt over hvilke automasjoner som aktiveres / deaktiveres ved hvilke statuser - Sikre at statusendringene er "robuste nok", feks når varmtvannsberederen er aktivert (gjennom en automasjon hvor den er aktiv bare på de 8 billigste strømtimene), og status settes til "borte" deaktivers automasjonen. Da må også switch til VVB deaktiveres i tilfelle VVB-switch er aktiv når automasjonen deaktiveres. Hvordan har dere andre løst dette? Det jeg gjerne skulle hatt tips om er hvilke funksjonsområder som burde brukes her og hvordan disse burde samspille. Feks, templates i configuration.yaml, scence, automations etc.

Jeg har nå fått nye dimmere fra MicroMatic. De gamle hadde firmware 0x00000036. De nye har 0x0000003a. Etter byttet har jeg ikke opplevd problemet med at lyset har blitt skrudd av og på igjen, slik det tidvis var med de gamle. Ut fra den informasjonen jeg fikk kan de ikke oppgraderes over Zigbee.

Da jeg for en god tid tilbake oppgraderte til 1.34.0 begynte der å dukke opp en masse feilmeldinger i UI uten at de ser ut til å påvirke noe stort. OWON CB432 sluttet samtidig å oppdatere energidata men de har jeg funnet en hack på slik at de gjør jobben nå (et shellscript henter data hvert 10 sek). Har prøvd å oppgradere uten suksess... Husker ikke nøyaktig hva som skjedde men den oppgraderte versjonen virket i alle fall ikke... Zigbee2mqtt er jo en super byggeklosse i et hjemmeautomasjonssystem men den MÅ jo virke for at det skal være noe stas... Har også en 1.36.1 installasjon som ikke oppdaterer "Last seen". Litt småirriterende men ikke noe kritisk, virker fint ellers...

Dette, https://github.com/Koenkk/zigbee-herdsman-converters/pull/7470 , er et eksempel på hva jeg mener. En endring som ble tatt inn bare minutter før en release. Den kan umulig ha vært testet eller vurdert særlig grundig.

Jeg har full forståelse for at det ikke er lett å teste. Men samtidig er jeg overrasket enkelte ganger over endringer de gjør uten å tenke på risiko og konsekvenser. Uten at jeg skal påstå noe så har jeg allikevel gjort meg noen tanker. Og det er at det er noen aktive i det prosjektet som mangler erfaring og ser på zigbee2mqtt som sin egen lille sandkasse. Samtidig som de som holder i trådene er litt for lite restriktive. Det er jo et problem med mange åpne kildekode prosjekter. Men de håndterer det på forskjellige måter og i zigbee2mqtt synes jeg de er for slappe når en tenker på hvor mange som bruker den og hvilke konsekvenser en feil får.

Eg fekk problemer med versjonen etter 1.35.2 så eg gjekk tilbake til 1.35.2 og kjører på den fortsatt 🙂 Veit ikkje hvor mange som jobber på Zigbee2mqtt men er nok vanskelig å få testet på alle kombinasjoner av hardware/software som er der ute...