Bjørn Mork

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.

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?

Vanskelig å si uten å vite hvilken versjon du har 😀 Du kjører update.sh scriptet. Evt leser det og utfører kommandoene som står der, evt med tilpasninger til din installasjon (f.eks. hvis du ikke bruker systemd). Se https://github.com/Koenkk/zigbee2mqtt/blob/master/update.sh for siste versjon. Prinsippet har vært det samme i lang tid, men jeg tror det er flikket litt på scriptet underveis.

Jeg har også sett det problemet der en gang i blant og er interessert i hva de kom fram til. Skjer heldigvis ikke ofte nok til at jeg ser det som noe stort problem. Mest irriterende ved at det gir automatiserings-skeptikerne vann på mølla 😀

Det er slik struct tm er spesifisert. tm_year er "year minus 1900". Se f.eks https://man7.org/linux/man-pages/man3/tm.3type.html

Kan ikke huske å ha sett et uttak som ligner på den tegningen. Det jeg har hatt av cat 5e og cat 6 uttak har sett ut som bildet ditt. Det er uansett enklere å koble etter fargemerkingen enn å bruke noen manual.

Jeg trakk en del slik 28 AWG "slim" cat6a i nykjøpt hus i fjor. Vil absolutt anbefale det hvis du har mye 16mm rør, eller behov for å trekke veldig mange parallelle strekk slik jeg hadde (gjenbrukte gamle tv-koaks rør og bokser, og de var ikke konfigurert i stjerne). Det er en drøm å jobbe med 4mm kabel når du trekker. Når det gjelder termineringen så er trikset å bruke materiell som er laget for 28 AWG. Du får både plugger og keystone-moduler som passer, og som er like enkle å jobbe med som annet cat6a-utsyr. Se f.eks https://www.direktronik.no/direktronik/kablar-5ba094bc/adapterepluggerdeksler/plugger/keystone-for-awg28/ https://www.direktronik.no/direktronik/kablar-5ba094bc/adapterepluggerdeksler/plugger/modular-kontakt3/ (merk at pluggen kommer uten bøyebskyttelse - det må kjøpes separat). Av estetiske årsaker terminerte jeg også i noen vanlige doble Elko cat6-uttak. Det gikk såvidt, men er nok ikke helt å anbefale. Måtte ha et par forsøk på et par av dem. Det er ikke et godt tegn. Ting som jeg prøvde og som abolutt ikke går: Vanlige plugger (cat5 eller cat6 spiller ingen rolle). Selv med dyp konsentrasjon og mye sikting så er det klin umulig å få 8 ledere til å holde seg på riktig plass når de er så tynne at de kan flytte seg sideveis mellom hullene mens du klemmer på tanga. Bruker PoE både her og der, men har ikke noe utstyr som trekker særlig mye. Det verste er vel wifi-aksesspunktene som peaker på en 10-15 W. Det er ingen grunn til å droppe slim kabel for slik bruk.

Omtrent som en zigbee lyspære som er slått av altså. Men i litt mindre praktisk innpakning for utendørs bruk, spør du meg.

Opplevde nettopp noe rart med en av disse dimmerne. Fikk ikke skrudd opp lysstyrken til mer enn en slags lunk. Hverken via zigbee, dimmehjulet eller trykknappen som er koblet til den aktuelle dimmeren. Lysstyrken bare stanset på nokså moderat lys, og spenningsmålingen viste ca 85 V. Dette er dimmeren som er montert uten N (aka den andre fasen). Ante ikke helt hvor jeg skulle starte feilsøkingen, men prøvde sikring av/på. Og det løste problemet. Men hva skjedde? Firmware-bug? Noen andre som har sett noe lignende?

Bruk mosquitto. Dønn stabil og relativt enkel å konfigurere akkurat som du vil ha den Har også god erfaring med vernemq når du trenger å støtte et stort antall sesjoner (hundretusener/ millioner). Men mye mer krøkkete å sette opp. Og erlang er ikke mitt førstevalg når noe må fikses på... Så jeg bruker mosquitto hjemme

Jeg gjetter støy eller strømunderskudd. RPi og usb radioer kan være litt små-kranglete. Ta en kikk på kernel loggen og se hvilke hint du finner der. Hvis det er stadige usb disconnects så får mest sannsynlig ikke donglen nok elektroner fra usb porten Både z2m og sonoff dongle-p er dønn stabile etter min erfaring.

Som @stigvi nevnte i en annen tråd ( ) , men som er mer relevant her: oppdatert z2m dokumentasjon forklarer hvordan dette skal gjøres Nå har jeg endelig testet, og det virker på en måte. Jeg kom dog bare så langt i oppskriften at jeg skulle binde brytermodulen til gruppen. Trigget bryteren for å være sikker på at den var våken, og lyset slo seg på Altså uten at bryteren er bundet til pærene/gruppen. Jeg kom bare så langt at jeg la til brytermodulen i samme gruppe som pærene, og gjorde unbind på coordinator. Legge til i gruppen ga bare feilmelding og brytermodulen dukker ikke opp som medlem. Men ettersom instruksjonen sier "Note that this device might not show up in the group, but this step is important." så tenkte jeg det var forventet og fortsatte. Unbind fra coordiator var vellykket. Dermed er altså status nå at brytermodulen hverken synes som medlem av gruppen eller som bundet til noe som helst. Men den styrer pærene like fullt... Veldig rare dingser.

Flotte saker. Der var jo https://docs.libretiny.eu/boards/cb3s/ også så da er esphome-sikringen sikret

Kanskje bare formfaktor? Ser ut til å være eksakt samme brikke og features: https://solution.tuya.com/hardware/detail/81001 https://solution.tuya.com/hardware/detail/82001

Ser ut til å være en slik: https://fcc.report/FCC-ID/2ANDL-CB3S/5246533.pdf

Ja. Du kan få inn TV selv om du bytter ut Telenor-ruteren med en annen ruter. Å legge inn OpenWrt på en Telenor-ruter blir i praksis det samme som å bytte ut ruteren. Da har du ikke noen Telenor-ruter lenger.

Dette er faktisk en av tingene som var veldig vanskelig å håndtere med lokal web-grensesnitt. Firmware-oppdatering er nødvendig. Slik er det bare. Hvorvidt innstillinger overlever eller ikke blir ofte litt bingo. Ved å overta management-grensesnittet kan vi tilby permanent lagring av alle innstillinger helt uavhengig av hva ruteren finner på. I de avanserte innstillingen på https://wifi.telenor.no finner du en "Tildel statisk IP til ditt ustyr" link under "DHCP". Der får du opp en oversikt over alle tilkoblede dingser og hvilken adresse de har fått. Krysser du av for "Statisk IP-adresse" så kan du endre den adressen til det du vil (innenfor det valgte subnettet selvsagt). Trykk "Lagre" og det blir med etter alle oppgraderinger, factory reset eller til og med bytte av ruter. Slik lagring i en database hos oss er selvsagt en opt-in greie.

Beklager, men om du skal ha en P8702 på nett med firmware fra 2017 så må du uansett ha en annen brannmur/ruter foran. Da kan du også enkelt blokkere TR-069. Firmwaren med lokalt web-grensesnitt er gått ut på dato for lenge siden. Mange har vært fornøyde med P8702. Men verden går videre. Av og til medfører det endringer som brekker eksisterende funksjonalitet. Det er selvsagt ikke så interessant for de som brukte det lokale web-grensesnittet at det hindret utviklingen av ruter-adminstrasjon for et massivt flertall av kundene. Men jeg regner med de fleste forstår hva utfallet blir i slike tilfeller. Det er selvsagt synd at denne ruteren heller ikke egner seg for OpenWrt. Men den er basert på Broadcom SoC og WiFi-brikker. Dvs at du ikke får AC, eller 5 GHz i det hele tatt, med OpenWrt. I praksis nokså ubrukelig. Eneste trøst er at en oppgradering til dagens "Ruter II", som også er laget av ZyXEL, gir deg den mest optimale hardwaren som finnes for OpenWrt i øyeblikket - med Mediatek MT7986 SoC og 3 Mediatek radioer. Så den kan ihvertfall gjenbrukes når den går ut på dato, eller du ikke lenger ønsker å bruke https://wifi.telenor.no (jobber i Telenor. fikler tidvis med slikt som dette både på jobb og som hobby)

Verden trenger en kattesensor!

Dokumentet som er linket her burde vel være mer enn nok til å få støtte i zigbee2mqttt, og dermed HA? https://community.home-assistant.io/t/ev-charger-with-zigbee-will-this-work-in-ha/674506

Kan ikke si noe om varmepumper. Men vi har svært forskjellige erfaringer mht kjøleskap....

Ville også vurdert BigBox på steder der du ser for deg at brytere skal bli smartere i fremtiden. Det skal ikke så mange klemmer til før det blir trangt bak en bryter. Alltid greit å ha litt ekstra plass til smartpiller eller dimmere.

Se https://www.zigbee2mqtt.io/advanced/zigbee/01_zigbee_network.html#green-power-devices Du må ha en eller annen vanlig zigbee-enhet i nærheten som kan fungere som proxy. En IKEA pære f.eks.