NilsOF

Debian (og sikkert de fleste derivater som Ubuntu, Raspian osv.) har ett "alternatives" system: root@bitfrost:~# update-alternatives --config java Det er 2 valg for alternativet java (som tilbyr /usr/bin/java). Valg Sti Prioritet Status ------------------------------------------------------------ * 0 /usr/lib/jvm/zulu11/bin/java 2114301 auto modus 1 /usr/lib/jvm/zulu11/bin/java 2114301 manuell modus 2 /usr/lib/jvm/zulu8/jre/bin/java 1805001 manuell modus Press <enter> to keep the current choice[*], or type selection number: root@bitfrost:~# Det setter default.

Nei, jeg ante ikke at den fantes engang. Det eneste jeg tenkte å bruke ZWay til var å oppgradere firmware. Og det ser jo tvilsomt nok ut! Dessuten, Z-Way gnåler om apper. Jeg er alergisk mot apper 😄

Fant denne tråden: https://forum.z-wave.me/viewtopic.php?f=3419&t=32646 Dersom den har følgende skrift på seg: "S/N 04/19 01" og den har firmware 5.27 så er det en stor sjans for at stikka dør ved firmwareoppgradering! Den jeg hadde har den skriften (og 5.27 firmware) Jeg har to i bestilling, men det er fra samme sted som den jeg har kommer fra..

Da har jeg omsider klart å installere Z-Way. Jeg har ikke Windows, heller ikke Ubuntus forvrengning av Debian. Debian-pakka var utdatert og ville ha et meget gammelt SSL-bibliotek. Derfor endte jeg op med å installere .deb -pakka for Rpi på en Rpi4, det gikk glatt! :-) Fikk startet Z-Way med: pi@dingle:/opt/z-way-server $ sudo LD_LIBRARY_PATH=./libs ./z-way-server Rotet litt rundt før jeg fikk UZB1 registert i Z-Way som /dev/ttyACM0 og fant til slutt ut at jeg skulle skrive all som token i expert-greiene. Da kunne jeg oppgradere fra 5.27 til 5.3noe. MEN dmesg fra Rpien: [247196.510046] usb 1-1.1: new full-speed USB device number 27 using xhci_hcd [247196.610306] usb 1-1.1: device descriptor read/64, error -32 [247196.830296] usb 1-1.1: device descriptor read/64, error -32 [247197.050062] usb 1-1.1: new full-speed USB device number 28 using xhci_hcd [247197.150311] usb 1-1.1: device descriptor read/64, error -32 [247197.370298] usb 1-1.1: device descriptor read/64, error -32 [247197.490595] usb 1-1-port1: attempt power cycle [247198.150071] usb 1-1.1: new full-speed USB device number 29 using xhci_hcd [247198.150344] usb 1-1.1: Device not responding to setup address. [247198.370310] usb 1-1.1: Device not responding to setup address. [247198.590080] usb 1-1.1: device not accepting address 29, error -71 [247198.690085] usb 1-1.1: new full-speed USB device number 30 using xhci_hcd [247198.690347] usb 1-1.1: Device not responding to setup address. [247198.910329] usb 1-1.1: Device not responding to setup address. [247199.130093] usb 1-1.1: device not accepting address 30, error -71 [247199.130684] usb 1-1-port1: unable to enumerate USB device Og ja, UZB1 jeg hadde er nå død som ei spekesild 😕

@GrøtanSupert, da begynner det å ligne på en plan hær 😄

Det ser ut som om det er lurt å bruke z-way for firmware-oppgradering i allefall. Iflg. kartet (i min første post) så har 5.39 ett ekstra firesiffret etternavn som har noe å si for hvor i treet av firmware-oppdateringer man havner. Hvordan er lisensieringen for z-way? Må man ha lisens for å få tak i firmwaren?

Hm, ser at 5.39 er siste versjon. Det spørs om jeg bare skal kjøpe to stk. fra samme sted for å øke sjansen for at jeg får to med lik firmware.. Dette med å reinkludere alt på nytt er noe jeg ser litt svart på. Definitivt noe jeg vil unngå i fremtiden også. Nå har jeg alle Items i configfiler, men likevel blir det litt jobb med search/replace.

Fant tråden https://www.hjemmeautomasjon.no/forums/topic/4461-restore-ikke-mulig-mot-uzb1z-net/ Det tyder på at det er en potensiell felle hær.

@berland Takk for bildet! Mine to Aeotec har den Aeotech logoen. Grunnen til at jeg ville gå for UZB er at det finnes ett kommandolinjeverktøy for Linux (både rpi kompatibelt og for i368) som skal takle både firmware-oppgraderinger og backup. https://z-wave.me/ZMESerialUpdater-manual/ Men så var det med firmwareversjoner på stikkene og backup/restore. Om noen har satt seg inn i dette vil jeg gjærne høre 😉 Mener jeg har sett en tråd hær inne om dette også, mener å huske at den tråden har blitt gammel nå.

Jeg har havnet i en litt kjedelig situasjon. For to dager siden oppdaget jeg noe rart med z-wave-nettet mitt, det var som om at stikka ikke sendte ordentlig signaler ut i meshet. Javel, da er det jo godt at jeg har backup av den. Men nei stikka, en Aeotec G5 som sto i boksen lot seg ikke lese av backupverktøyet, og det gjorde ikke backupstikka mi (også en Aeotec g5) heller. Den sier noe om eeprom/rom feil. Problemet er bare at innholdet på backupstikka er et år gammelt.. .. men den virker med de nodene som ligger inne på den Så prøvde jeg en UZB1 i Aeotec sitt backupverktøy, og den lot seg lese. Nå tør jeg ikke skrive noe av de backupene jeg har til noen av stikkene mine.. Så jeg får ta jobben med å inkludere alt fra begynnelsen, det er ikke så mange, men en del er plassert litt kinkig til. Så for å unngå dette i fremtiden tenkte jeg å gjøre som planlagt (for lenge siden, men andre ting har alltid kommet i veien): Å gå over til UZB. Men så var det dette med firmware og kompatible versjoner. Se på dette: https://service.z-wave.me/expertui/uzb-stats/versions-graph.html 😕 😕

hehe, jo, men bare om man regner inn komfort og praktiske ting som tørking av klær. Forutsatt at doen ikke er på badet, da. Da slår sikkert komfortregnskapet den andre veien 🙂

Når jeg plukket opp HABApp i løpet av fjoråret, så hadde jeg ikke rørt Python på 15 år. Og fortsatt feiler jeg på selvfølgeligheter i Python.🙂 Og den lærekurven hadde blitt usigelig mye brattere om jeg ikke hadde hatt PyCharm å lene meg på. Holder på med værdata fra met.no nå, bruker https://github.com/Rory-Sullivan/metno-locationforecast. Til nå er jeg forbauset over hvor lite kode jeg måtte skrive for å få det jeg trenger levert til OpenHAB som jeg vil ha det. Observerer at Jython fortsatt henger på 2.7 og for meg er det uklart når og hvor mye endringer det blir til noe som ligner Python 3.x. Siden jeg fortsatt har huller i kunnskapen om hvordan grunnelementene i OpenHAB er tenkt til å fungere så vil jeg fortsette å lappe med det gamle scriptspråket til de enklere tingene. Mye skjer med OpenHAB v3 nå, og jeg har bestemt meg for å fortsette med configurasjonsfiler for Items en stund til. V3 har ennå noen sprekker og ustabiliteter, jeg tror jeg venter til det grøvste støvet har lagt seg.

Ja, chromecast (som eksempel) bruket broadcast, som pr. definisjon er begrenset til sitt eget nettvekssegment, og et eget nettverksegment (==netverk og maske) er det man typisk har separat for hvert VLAN. Det finnes måter å repetere broadcast mellom forskjellige netverkssegmenter, men etter erfaring kan det fort bli hårete og det igjen krever inngående kjennskap til tcp/ip/arp. En annen måte er putte firewallregler mellom to VLAN med samme nettverk, aka. bridged firewalling. Dette er heller ikke uten skarpe kanter og skrukker, som igjen fort krever dypdykk i detaljerte deler av nettverking. Mange router/brannvegg -produsenter hevder at de har løst disse problemene og at man klikke på et par ikoner og DITT problem er løst. Etter mitt syn er det som å vinne i lotto, da alle har forskjellige ting de ønsker. Og, ja, det er enklere å vinne i lotto om sjansen for å vinne er 50%. Det vil si: Enten har du internet, eller så har du ikke. Om du har en ruter/brannvegg med bridged VLANs der det ene VLANet kan stenges av på egenkonfigurerbart tid etter forgodtbefinnende så er man i mål. 😄

Hm, nesten så jeg må anbefale en luftavfukter igjen. Den vil øke temperaturen i rommet når den avfukter, derfor kjører jeg avtrekksvifta kun når det er sommer og varmt ute samt varmt på badet. Dessuten alt under 50% rel.hum. er vel å oppfatte som tørr luft. Uansett dur på, artig å se hva du får ut av det! 🙂

Forøvrig, for fuktproblemet i dette tilfellet er kanskje en luftavfukter noe å vurdere. En avfukter generer også varme i avfuktingsprosessen, noe som er bedre enn å dra ut oppvarmet luft som man har brukt energi på å varme opp. Forutsatt da at man har varme på. Bare en tanke.. 🙂

Viftehuset ser mistenkelig likt ut med det jeg har. Produsert av Witt. Har fundert så smått på å automatisere, men ikke sett på elektronikken enda. Min har forøvrig en fjernkontroll, men regner med at styrepanel og elektronikk varierer med leverandør og modell. Og, ja, den slurper inn luft så det nesten er for meget, selv på laveste instilling.

Du mister ikke så mye.Det bare ser sånn ut inne i Unifi med store ikoner som sier utilgjengelig. I praksis så betyr dette ingenting. Jeg fant også unifi routerene for lette, men av helt andre grunnet. Ubiquiti har en jobb å gjøre dær. Synology vet jeg ingenting om.

Man angrer definitivt på den sparte hundrelappen når man må frem med den lange stigen, det blåser pinnjævler, er godt under ti minus og det striregner.. ..føles sånn omtrent. Uansett hvilken dings som må fikses.

Ikke hypotetisk, jeg måttet bare knø meg til å finne posten.. hele tråden bør leses, men siden jeg er den siste som dokumenterte så linker jeg til min post med deler fra Elfa. Ps: Det finnes en Huzza ESP8366 med innebygget USB om man ikke har "programmerer" liggende. https://www.hjemmeautomasjon.no/forums/topic/4424-ekstern-temperaturføler-til-mitsubishi-varmpepumper/?do=findComment&comment=75540 https://www.hjemmeautomasjon.no/forums/topic/5516-tips-til-varmepumpe-ordentlig-styring-ikke-ir-ikke-sky/?do=findComment&comment=63870 Mener det var flere poster også, men tror det forsvant noe i forumkrasjet..

Den største utfordringen med Mitsubishi vp og ESP8266 er muligens å få programmert ESPen. Dvs. det krever at man setter opp og manøvrerer Arduino-IDEen. En MQTT-service må settes opp Og så må man plugge fire ledninger riktig. Ellers er alt å få kjøpt ferdig. Ingen lodding nødvendig. Men helt klart en høyere vanskelighetsgrad, inkludert at man må av med dekslene på varmepumpa for å plugge inn ESPen.

Hvordan er erfaringen med Osram/Ledvance -pærer? Jeg må ha flere pærer og vil gjærne plassere disse også i forhold til Hue og Ikea. Ikea sine er OK til sitt bruk, men ikke like bra som Hue. Jeg har noen som har resatt seg et par ganger da strømmen slo inn og ut som en annen jokkepetter. Ganske godt gjort, då å få resatt disse når man vil er en tålmodighetsprøve. Jeg har Ikea sine 1000lm i utelysene og de har nå passert sin første -20C. Og siden de er i utelys er det ikke så viktig hvordan de takler dimming og fargetemperatur sendt i en smekk.

Vel, melcloud var ikke brukbart for meg, da den er avhengig av "skyen". Det blir for mye som kan gå galt etter min smak.

@braekk Jeg bare nevner dette da Hue-hubben har noen kjente begrensninger mot omverdenen. Jeg vet ikke hvor mange telefoner og apper og systemer som prøver å snakke samen i dette tilfellet. Jeg ga opp Hue-hubben da jeg prøvde å dra Hue-dimmer-fjernkontrollen ut av hubben. Det er umulig å ikke miste tastetrykk feks. Det eneste ikke-Hue jeg har prøvd på hue-hubben er Ikea-pærer. Etter husken gikk heller ikke det like glatt som reklamen..

En ting med Hue -hubben: Alle dingser som snakker med den over ethernet MÅ bruke polling. Det må da spørres spesifikt for hver enkelt status på alle dingser. Så har man noen pærer og utstyr så blir det fort trafikk av det om man har flere telefoner med flere apper og annet som skal ha status inn og ut fra hubben. Begrensningen ligger i API. Med forbehold om at API har blitt vesentlig smartere de siste månedene..

Enkelt og enkelt. Har en kaiteki med en ESP8266 implant. En meget go løsning! Om du søker litt i forumet så finner du mye informasjon 🙂