VikingOy

Nei, min NodeRED implementering fungerer helt utmerket. Akkurat nå ser det slik ut:

Jeg har ikke fulgt hele tråden, men du er selvfølgelig klar over at det er ikke nok bare å ha en AMR måler med HAN port. Du må i tillegg ha en nettleverandør som kan åpne porten og levere måledata.

Denne guiden tar utgangspunkt i xComfort Bridge. Jeg har ikke tilgang til Smart Home Controller'en eller Sensio utstyr. Som de fleste vet, er det ikke helt rett frem å kunne styre xComfort enheter fra Home Assistant. Det finnes en veldig bra integrasjon xComfort Integrasjon. men vedlikeoldet av denne har stoppet litt opp og bl.a. så fungerer ikke styringen av xComfort sine aktuatorer for vindu's skjermer (cover.py) fullt ut. Som kjent innførte Eaton full integrasjon mot Alexa og Google Home (delvis) for en tid tilbake. Løsningen min ble derfor å å kommandere Alexa til å styre xComfort enhetene - fra Home Assistant. Jeg startet med å styre vindu's skjermene (Window Screens). Det finnes en custom integration ved navn Alexa Media Player som kan benyttes til dette. Ja, det høres kanskje litt merkelig ut å skulle bruke en Media_player til å fjernstyre solskjermer og lamper, men det fungerer faktisk helt greit. Det finnes en offisiell Alexa integrasjon, men hensikten med den er å eksponere HA entities til Alexa. Det er ikke påkrevd å installere denne for å kunne benytte Alexa Media Player integrasjonen. Det kan være litt kronglete å installere Alexa MediaPlayer integrasjonen. Min anbefaling er å benytte HACS til dette samt å følge dokumentasjonen slavisk. Her blir du anbefalt å aktivere 2-Factor-Authentication (2FA), eller 2-Step-Verification (2SV) som Amazon kaller det. Er du opptatt av sikkerhet, kan det lønne seg, men det gjør førstegangspåloggingen for integrasjonen litt kronglete. Du vil få en feilmelding. Da må du kopiere URL'en og bryte ut i et nytt browser vindu og paste denne inn der og manuelt gå gjennom 2FA påloggingen første gangen. Deretter går det greit. Her er en automasjon som vha en IKEA on/off bryter integrert via deConz/Phoscon som kjører solskjermen opp og ned: alias: Close-Open screen description: "" trigger: - platform: event event_type: deconz_event event_data: device_id: 8d5661146e8a32179bfbb2e2445e364f condition: [] action: - variables: command: "{{ trigger.event.data.event }}" - choose: - conditions: - "{{ command == 1002 }}" sequence: - service: media_player.play_media data: media_content_id: Open Screen media_content_type: routine entity_id: media_player.my_echo_dot - conditions: - "{{ command == 2002 }}" sequence: - service: media_player.play_media data: media_content_id: Close Screen media_content_type: routine entity_id: media_player.my_echo_dot mode: single Dersom du kjører HAOS og benytter ZHA (i steden for deConz) så blir koden slik: alias: Close-Open screen description: "" trigger: - platform: event event_type: zha_event event_data: device_id: 90f50ccf9a8a96682083943d78dc0978 condition: [] action: - variables: command: "{{ trigger.event.data.command }}" - choose: - conditions: - "{{ command == 'on' }}" sequence: - service: media_player.play_media data: media_content_id: Open Screen media_content_type: routine entity_id: media_player.my_echo_dot - conditions: - "{{ command == 'off' }}" sequence: - service: media_player.play_media data: media_content_id: Close Screen media_content_type: routine entity_id: media_player.my_echo_dot mode: single Løsningen krever at du først etablerer (oppretter) 2 nye rutiner i Alexa Appen på din mobiltelefon: Open Screen og Close Screen. Her er en skjerm dump på en av disse - som et eksempel: Rutiner opprettet i Alexa exponeres automatisk gjnnom MediaPlayer integrasjonen. Det er ingen begrensninger på hva du kan styre. Jeg kombinerer dette med HA bl.. på den måten at jeg har en lysmåler integrert i HA (noe som ikke finnes for Alexa) som trigger automasjonen når lyset fra sola passerer 1500 lux. Da går skjermen automatisk ned.

Av ren nysgjerrrighet - hvorfor bytter du?

Det var ikke min hensikt å promotere NodeRED ut over hva jeg selv har erfart. Andre må mene og velge det de syns er best. Noe av hensikten med dette fora er å formidle metoder og løsninger man selv har funnet, samt å få hjelp til å løse problemer og tips til forbedringer. Slik ser nå min NodeRED Flow ut, etter at jeg har forenklet og trimmet den litt: Og slik er resultat i HA blitt. Søket gjøres blant 30 utvalgte stasjoner mellom Oslo vest og Asker.

Ja, ja - hver sin smak. Men NodeRed opererer ikke med begrepet "sensor" og ingenting lagres noe sted i egne registre. Ditt valg innebærer at data for en haug sensorer oppdateres i HA konstant. Det blir mye unødig trafikk og i og med at disse sensorene ikke kan vedlikeholdes i frontend, så må du "under panseret" for å slette etc. NodeRED er uavhengig av hvilken Home Automation platform man benytter. Bensin-eksempelet kan like gjerne sende dataene til Homey, Alexa eller annet bare ved å endre på den ene siste noden. Resten forblir uendret.

Det virker litt "overkill" å lage en sensor for hver eneste besinstasjon. Jeg har isteden gjort alt ferdig i NodeRed med bruk av JavaScript og ender opp med kun en enkel sensor som jeg så sender til Home Assistant. Enkelt, rent og ryddig. Først trekkes alle de ønskede stasjonene ut og samles i en felles array (eksempelet her har kun 3 stasjoner): var stasjoner = []; var temp = msg.payload.filter(e => e.discountInfo == 'Shell Marienlyst'); temp[0].stationDetails = temp[0].stationDetails.filter(e => e.type == 'D'); temp[0].stationDetails = temp[0].stationDetails[0]; stasjoner[0] = temp[0]; var temp = msg.payload.filter(e => e.discountInfo == 'Shell Frogner'); temp[0].stationDetails = temp[0].stationDetails.filter(e => e.type == 'D'); temp[0].stationDetails = temp[0].stationDetails[0]; stasjoner[1] = temp[0]; var temp = msg.payload.filter(e => e.discountInfo == 'Shell Vinderen'); temp[0].stationDetails = temp[0].stationDetails.filter(e => e.type == 'D'); temp[0].stationDetails = temp[0].stationDetails[0]; stasjoner[2] = temp[0]; msg.payload = stasjoner; return msg; Deretter sorteres tabellen og den billigste trekkes ut: var billigst = msg.payload[0]; msg.payload.forEach(FinnBilligst); function FinnBilligst(stasjon){ if(stasjon.stationDetails.price < billigst.stationDetails.price) { billigst = stasjon; } } msg.payload = billigst; return msg; Resultatet sendes til HA som én sensor: Og presenteres i Lovelace:

Min forståelse er at dette API'et ikke er åpent og fritt tilgjengelig. Det er nok en eller annen IT-dyktig luring som har funnet det og gjort en eksperimentell reverse engineering. Det kan bety at API'et når som helt kan forandres og slutte å virke. Det er en del av gamet. Men, så er det gjerne slik at selskapet bak ofte velger å se gjennom fingrene med at det alltid vil være noen som "finner" frem til slike API'er fordi de som bruker slike for det første ofte er i veldig fåtall (nerdene som oss), og dernest så er all markedsføring, god markedsføring. Vi er med å sprer info om eksistensen til Drivstoffappen.no. Og sist, men ikke minst - vi bidrar nok også med en del verdifull tilbakemelding dersom Drivstoffappen.no gidder å ta seg bryet med følge litt med på forumene våre. Kall oss gjerne gratis betatestere.

Ja, selvsagt - det gikk litt fort i den svingen 🙄

Slettet.

Etter å ha juster litt på utvalget, endte jeg opp med dette i HA: Jeg opplever ingen forsinkelser eller påvirkning av andre funksjoner hverken i HA eller på annen programmvare som kjører.

Jeg la inn NodeRed Flow'en som lå på FaceBook, og det fungerte helt greit.

Har du en link til Facebook som du viser til ?

Oj, oj - det var leit. Men takk for svar. Da vet man i det minste det.

Nei, nei - det har da ikke jeg noe med. Det jeg egentlig lurte på var om du har funnet ut av om du trygt kan levere den tilbake igjen, eller om du må ha den på ubestemt tid fordi du vil komme til å trenge den hver eneste gang du gjør en liten endring i xComfort nettet ditt (f.eks. kjøper og legger til en ny aktuator eller bryter). Det er slik informasjon som er nyttig for oss andre for å avgjøre om det å "låne" en 00/13 er ok, eller om man like gjerne kan bite i det sure eplet og betale den overprisen Eaton skal ha for en slik dings fordi man dessverre ikke kan klare seg uten begge to (00/13 og 00/14) i det lange løp.

Endte du opp med å kjøpe en 00/13 eller fikk du "låne" en?

Det kan umulig være ment at dette skal være så vrient å få til. Det gjør det jo i så fall helt utilgjengelig for de fleste. Blir spennende å se om du får nok hjelp til å løse flokene.

Så bra. Jeg er veldig spent på om du får dette til. Jeg har behov for det samme selv også. Jeg har en 00/14 koblet opp til en NAS men ingen 00/13. Fint om du noterer ned steg-for-steg det som må gjøres for å få det til , så kan du dele det her på forumet etterpå?

Betyr det at store deler av hele nabolaget er "raidet" av Eaton og har tilsvarende ustyr installert? Uansett, dersom du har mange aktuatorer og brytere installert, så kan det jo lønne seg å investere i en 00/13 fremfor å bytte ut alt.

Jeg antar at huset du har kjøpt er utstyrt med kun den "gamle" serien av Eaton aktuatorer (uten extended status message) ? Videreutviklingen av denne serien har stoppet helt og ingen av disse enhetene er kompatible med nye xComfort Bridge. Utfordringen med Eaton's xComfort produkter er jo at de er så dyre at kun et par aktuatorer koster like mye som en en hel sekk med z-Wave eller ZigBee aktuatorer. Uansett, har du en CKOZ-00/14 så må du i tillegg ha en 00/13 også for å komme igang mot Home Assistant.

Jeg tror det kan bli lettere for deg å få hjelp dersom du i detalj beskriver hvordan du oppgraderte firmware i din ConBee, samt fra hvilken versjon og til hvilken versjon.

Jeg strevde litt med å få integrert IKEA STARKVIND luftfilteret inn i Home Assistant via ConBee II og deConz. Ikke noe sted fant jeg en DDF som virket. Resultatet ble at jeg valgte å gå veien om API'et og jeg er fornøyd nå. Her er min oppskrift - riktignok på engelsk, men dog 🙂 How to control the IKEA STARKVIND AirPurifier via REST-API.pdf

Jeg bestilte og betalte i februar, og har ikke hørt et pip om levering.... ?

Hei, ser at denne tråden begynner å bli gammel, men @Saggis, har du noen formening om det å bruke CKOZ-00/13 til å bygge opp en DATAPOINT fil for CKOZ-00/14 på noen måte vil forstyrre et eksisterende oppsett mot xComfort Bridge? Alternativt om det er mulig å lese ut DATAPOINT tabellen fra Bridge og deretter skrive den over til CKOZ-00/14 ? Mon tro om Bridge og CKOZ-00/14 faktisk kan sameksistere i samme configurasjon? Jeg ser at de selger begge deler hos Elketroimportøren, men det finnes jo ingen der som begriper det pøkk om hvordan noe av dette faktisk fungerer. Og produsenten har heller ingen support tjeneste for sluttbrukere (eller forum). Og de elektroinnstallatørene de bruker vet omtrent hva som står i brukerveiledningene, og ikke særlig mye mer. Så vi må klare oss selv og dele kunnskap og erfaringer med hverandre.

2011 ?? Jeg håper du mener 2022!