iotux

Jeg ønsker meg ssh-tilgang og har tatt mot til meg for å åpne min FH Hub 2. Slik jeg ser det, er det ikke mye å hente. USB-C ser ut til å bare forsyne enheten med strøm. Koblet til PC, er det ingen tty som aktiviseres. Det er heller ingen JTAG synlig på kortet. Derimot er det tydeligvis en UART eller to der. Det mest lovende stedet er de 4 rektangulære loddepunktene på bilde FH-4. Der kan det være en mulighet for en vei inn, men
med mine 80 år og skjelven på hånde, er nok ikke jeg den rette til å prøve meg med loddebolten.

Når jeg først er inne på det, så kunne det være kjekt å fikse ethernet til å beholde MAC-adressen etter en reboot. Å gå inn på ruteren i etterkant og sette ipaddresse etterpå er i beste fall plagsomt.

For de som fortsatte ønsker å bruke enheten uten app, så leverer den meningsfylte MQTT-meldinginger.All automatisering må i så fall gjøres utenfor enheten (Home assistant eller lignende). Etter at Futurehome kutter tråden, er det ikke lenger mulig å laste ned apper til huben (tror jeg).

Et tips til de som vil beholde huben uten å bruke app. Aktiviser Thingsplex og download alt du kan tenkes å ha bruk for av
integrasjoner. Da vil du få alt av MQTT-meldinger. De kan være litt forvirrende, men det går an å  finne ut av.

9 hours ago, Bjørn Mork said:

Det er som sagt en ukjent protokoll på 868 MHz, så det er ikke hverken enklere eller vanskeligere enn med alle andre trådløse røykvarslere. Zigbee varslingen utløser neppe noen lyd. Den er bare for apper og automatisering

Du har sikkert rett, men det er ikke til å underslå at alle varslerne lager et helvetes bråk når man tester med å holde knappen inne ca 10 på en enkelt varsler. Er det noen radioamatører her? 

PS: huben får med seg at varslerne har blitt testet 

Nå mangler det bare finne ut hva de sender til hverandre når de melder brann, så kan man få en effektiv sirene hvis noen bryter seg inn i huset 

Jeg har brukt en Futurehome hub for å koble sammen Elko-varslerne. Kommunikasjonen mellom dem virker helt fint. Jeg husker ikke nå om det ble testet med eller uten hub. Hovedgrunnene til at jeg valgte Elko var batterilevetid og sammenkobling. En sekundær grunn var at den har temperatursensor, men sensoren skuffer i forhold til temperaturstyring. Det tar evigheter mellom hver rapportering av temperatur. Jeg har noen teorier om grunnen.

1. Den melder ikke temperatur med mindre det er en endring i temperatur
2. Enheten sparer strøm for å opprettholde levetid på batteriet
3. Huben "gidder ikke" videresende alle innkommende meldinger.

Vedr. 1: Den trenger ikke nødvendivis være uegnet som temperatursensor hvis dette er grunnen såfremt den rapporterer i tide.

Vedr. 3: Mistanken kommer fra erfaring med å bruke Futurehome sin HAN-sensor for å lese av en Kaifa AMS-måler. Huben rapporterer med intervaller som er fjernt fra det som Kaifa-måleren rapporterer. Dette vet jeg sikkkert fordi jeg har en Tibber Pulse på en annen identisk Kaifa-måler. Det mangler også verdier fra datasettet som Kaifa leverer.

Her er et eksempel på "Åpne dør" med MQTT-melding, laget via web-grensesnittet:

I "automations.yaml" ser det slik ut:

alias: Åpne dør
description: ""
triggers:
  - trigger: mqtt
    topic: door/lock
    payload: unlock
conditions: []
actions:
  - device_id: d3d3776b68abb6b5ec328c405d0c5170
    domain: lock
    entity_id: 9e344ce79a0aacc6ba3eaa40c1916642
    type: unlock
mode: single

Her er et eksempel på hvordan du kan lese ut flere verdier som restultat av 1 MQTT-melding:
 

alias: Yale status
description: Dør batterinivå
triggers:
  - topic: door/lock
    payload: status
    trigger: mqtt
conditions: []
actions:
  - action: mqtt.publish
    data:
      topic: door/lock/battery
      payload: "{{ states('sensor.front_door_battery') }}"
  - action: mqtt.publish
    data:
      topic: door/lock/status
      payload: "{{ states('lock.front_door') }}"
mode: single

Du kan sjekke ved å åpne to vinduer og kjøre disse, en i hvert vindu:

~$ mosquitto_sub -v door/lock -m status
~$ mosquitto_sub -v -t door/lock/#
 

On 09/11/2024 at 09:25, SveinHa said:

Jeg har et sannsynligvis veldig enkelt prosjekt men kjenner overhodet ikke HomeAssistant. Der finnes jo en god del muligheter for å få Yale låser inn i Node-RED men jeg sliter med å få de til å virke i tillegg til at de som utvikler slike ting sliter med kostnader med å holde slike integrasjoner i drift. Mange av de integrasjonene som finnes har ikke blitt oppdatert på en håndfull år og mer...

 

Har brukt en dag på å få HomeAssistant opp å gå. Ville helst ha HA oppe å gå på virtuell Linux maskin og prøvde flere forskjellige varianter av installasjoner men ingen ville samarbeide med meg så jeg endte opp med en RPi 3B+ som kom opp og gå på første forsøk. Har installert integrasjoner for både Yale Home og MQTT men hvordan få koblet disse sammen på en enkel og elegant måte?

 

Ønskeliste:

1. Sende kommando "lås"/"lås opp" til hver enkelt lås via MQTT fra andre system (Whatever=>MQTT=>HomeAssistant=>Yale Home=>dørlås).
2. Motta status fra låser (Dørlås=>Yale Home=>HomeAssistant=>MQTT=>whatever). Det ser ut til at hver lås har 11 statuser der jeg i alle fall har bruk for mange av de: 

Hvordan gjøre koblingen mellom HomeAssistant og MQTT? resten ser ut til å være oppegående av seg selv.

Søk opp og installer Yale-integrasjonen (https://www.home-assistant.io/integrations/yale). Deretter er det ganske rett fram. Her er et par kort du kan bruke:
 

Hvis du bruker Yale sin app, så kan du til og med låse inn innbruddstyven når du er borte hjemmefra 🤪

Oppdatering oktober 2024.

Jeg har nettopp testet Elko smarte røykvarslere. 5 stykker ble paret enkelt med Futurehome Smarthub II, og varslerne blir sammenkoblet uten mere mikkmakk.

Ettersom Futurehome har et åpent API of MQTT, så er veien kort fram til Home Assistant. 

Batteriet skal holde i 10 år. Det har vært det viktigste valgkriteriet ettersom jeg har leietaker og jeg ikke føler meg trygg på om batterier blir skiftet.

En annen faktor er at de har temperatursensorer som kan erstatte noen av mine hjemmesnekrede ESP32 m/LHT22 som er foret med strøm fra usbladere fra IKEA. 

Prisen er litt høy (nærmere 1000-lappen fra Elektroimportøren), men denne passet enkelheten meg bedre enn å fikle for mye selv. 

Innmaten er Schneider Electric sin W599001 Wiser Smoke Alarm.

Ved testing av alarmen flasher Futurehome sin app ganske tydelig hva som foregår med oppfordring om å ringe brannvesen eller kansellere alarmen.

Offisielt går det ikke å trigge alarmen via API, men jeg regner med at det skal være mulig å emulere signalet som sendes til de øvrige varslerne.

2 hours ago, sbarmen said:

Ja jeg kan det, ønsker å holde meg mest mulig uavhengig av cloud og eksterne tjenester så det står egentlig på listen min å bli enda mer uavhengig av Tibber ... 

Check this: 

ElWiz har fått en oppdatering med graf som viser priser. Grafen oppdateres når morgendagens priser er tilgjengelig. Som regel skjer dette ca kl 13 hver dag. 

Grafen baserer seg på priser fra enten Nord Pool eller Entso-E. Lokale priser bestemmes ved å angi aktuell sone. Grafen er delt i to soner, grønn sone når timeprisen er under gjennomsnitt for døgnet og rød sone når prisen er over gjennomsnitt. Soneterskelen kan heves eller senkes fra et tilpasset "kort" i Home Asssistant eller ved å sende MQTT-meldinger til programmet. Ved overgang til ny time, sendes en MQTT-melding som viser om prisen er under eller over terskelverdien. Denne meldingen kan slå enheter av eller på I Home Assistant. Programmer krever en Tibber pulse satt opp til å snakke med egen MQTT-broker.

Det er verdt å merke seg at grafen ikke er avhengig av HACS.
 

https://github.com/iotux/ElWiz/blob/master/docs/elwiz-chart.md

Mer info her: https://github.com/iotux/ElWiz#elwiz---a-program-to-read-data-from-tibber-pulse

Pussig sammentreff. I går har noen forsynt seg med Kaifa-dekoderen fra ElWiz og brukt den i en fork av "node-red-contrib-ams-decoder-mod".

https://github.com/jh1982/node-red-contrib-ams-decoder-mod/blob/main/src/ams_decoder_kaifa.js

Her er originalkoden: https://github.com/iotux/ElWiz/blob/master/ams/kaifa.js

Jeg måtte forsyne meg litt selv for å implementere en Kamstrup-dekoder for ElWiz. Ironisk, ikke sant?

Slik er det med åpen kildekode 🤓

@MHR Har du sjekket denne? Den er oppdatert i dag med integrering mot HA. Den strømmer data fra Tibber Pulse rett inn i HA. Enkel konfigurering og enkel installasjon.
https://github.com/iotux/ElWiz

Jeg kikket raskt på spec-en og blir skeptisk når de skal kobles til en skytjeneste. Jeg vet ikke om det er påkrevet, men bare det at det nevnes gir meg frysninger på ryggen. Jeg bruker en MikroTik CCR1009-7G-1S+ mot Altibox, og med den styrer jeg separate nett for eget bruk, IoT, DMZ og leietaker. Den leverer glatt også IPv6 i Altibox sitt nett. Det finnes veiledninger hvordan du setter opp denne mot Altibox i forskjellige forum, bl.a. denne https://freak.no/forum/showthread.php?t=313333 

MikroTik har også andre modeller som er egnet til dette bruket.

Informasjonen som du finner her vil du ha stor nytte av:

https://www.home-assistant.io/docs/mqtt/discovery/

HA er kresen på hvordan du setter sammen discovery topic:

<discovery_prefix>/<component>/[<node_id>/]<object_id>/config

Standard er "homeassistant/<component>/<object_id>/config
component kan f.eks være "sensor", "binary_sendor" osv.

Viktig (sitat):

"The <node_id> level can be used by clients to only subscribe to their own (command) topics by using one wildcard topic like <discovery_prefix>/+/<node_id>/+/set.

Best practice for entities with a unique_id is to set <object_id> to unique_id and omit the <node_id>."

Du kan også ha hjelp i å se på koden her:
https://github.com/iotux/ElWiz/blob/master/elwiz.js

Funksjonene hassDevice() // linje 273
og hassAnnounce() // linje 301

Funksjonen hassDevice() blir på en måte en "mal" som brukes for alle sensorene. Du må selvfølgelig gjøre dine tilpasninger.

Den delen som er innrykket ekstra: "dev: {}" er lik for alle sensorene. Denne er viktig å ha med når du annonserer hver enkelt sensor (id: #) for å få samlet alle sensorene under "en hatt". Det ser ut som det er "SlaveInformation" som skal inn i "dev: {}". Det må du få inn med nøkler som HA kjenner igjen.

Det er også viktig å sette retain til true for at HA auto discovery skal virke.

Jeg vet ikke om jeg har forklart det tydelig nok her, men du kan forsøke

ElWiz har ferdig integrasjon for Home Assistant. Når ElWiz starter opp, så vil programmet "oppdages" av HA sin auto discovery-mekanisme. Dette kommer fram i listen over Enheter i HA. Der presenterer ElWiz seg som ElWiz Pulse Enabler. I panelet Energi kan deretter ElWiz registreres som hovedkilde for importert strøm.

Lettere oppdatert dokumentasjon: https://github.com/iotux/ElWiz/blob/master/README.md

Mer dokumentasjon kommer.

Grafen i Energi-panelet oppdaterer seg automatisk basert på totalforbruket (Last meter consumption)

SveinHa skrev (På 10.6.2022 den 14.55):

Prøvde meg et par timer med ElWiz i dag men fikk ikke gang på Tibber Pulse. Første forsøk var på en virtuell Linux Mint maskin men der feilet de fleste av npm installasjonene men det gikk langt bedre på en RPi. Da jeg ga opp brukte jeg en time på å få den tilbake til Tibber appen... Prøvde å følge instruksjonene så godt jeg kunne både for ElWiz og Tibber og plutselig fikk jeg liv i den igjen i Tibber appen uten at jeg skjønner hva som gjorde at den plutselig virket...

 

Brukte litt tid på å oppdage at i Tibber Pulse stod default mqtt port til 8883 og ikke 1883...

 

Noen som har ElWiz oppe og gå som kan fortelle litt...?

Den gode nyheten er en større oppdatering av ElWiz Nytt er funkskjonalitet for auto discovery i Home Assistant. Etter installasjon og litt justering i configfila glir den rett inn i HA. Anbefales å prøve hvis du har sterkt hjerte.

ralm skrev (På 11.10.2021 den 12.08):

Har anskaffet en Tibber Pulse som jeg har forsøkt satt opp mot lokal MQTT (i hht tidligere info i denne tråden). Den kommer opp med Web-snitt helt OK, viser versjonen som 1.1.13. Men både uten sertifikater (port 1883) og med selvgenererte sertifikater (port 8883) får jeg ikke noe forsøk på oppkobling mot lokal MQTT.

Jeg ser at den kobler til lokal-nettet og svarer på to-tre ping-pakker før den returnerer til Web-snittet.

Er det noen som har lykkes med å koble opp denne versjonen av firmware til lokal MQTT ?

PS: Ser at det er gjort endringer på HW etter det bildet som er vist tidligere i tråden. Nå er tilkoblingene på SuperCAP'en vendt mot ESP32 og debug-pinnene ligger rett ved prosessoren.

Det kan eventuelt tyde på at du ikke får lagret innstillingene. Vær obs på at du også må fylle ut "update_url" for å få det til å virke. Jeg er usikker på hvordan "Send form data to the device" og "Try the current settings" virker i forhold til hverandre. Du kan prøve litt forskjellig rekkefølge. Det er flere som har fått dette til å virke. 

På 14.10.2020 den 22.23, dmncr skrev:

Har skaffat en Tibber Pulse och prövat ElWiz, det fungerar finfint. 

Testade inte funktionerna ift elpris utan har bara kopplat pulsen mot en mqtt broker, sedan pushar ElWiz tillbaka förbruket som home-assistant plockar upp med en mqtt sensor och skriver det vidare till en influxdb.

 

La upp en image på dockerhub och forkade @iotux repo och la till en Dockerfile + en docker-compose om någon är intresserad:

 

https://github.com/dmncr/ElWiz

https://hub.docker.com/repository/docker/dmncr/elwiz

 

All cred till @iotux som gjort de tunga lyften! Mkt bra jobbat! 

Takk for hyggelige ord, @dmncr Jeg bruker ikke docker selv, men det er skikkelig kult at du har forket ElWiz og laget en dockerfile. 🙂

På 15.10.2020 den 10.40, Mathias skrev:

Mulig det står i beskrivelsen og kanskje er nevnt over her, men jeg spør allikevel. Fungerer EIWiz parallelt med integrasjonen mot Tibber sin app slik at man kan kjøre begge deler samtidig?

Når du installerer appen, vil den sette inn Tibber sin broker, og din tilgang til Pulse vil være avskåret. Kommunikasjonen vil etter det gå mellom Pulse og Tibber. Derfra er så vidt jeg kan skjønne den eneste muligheten å bruke Tibber sitt API.

1 time siden, GadgetMan skrev:

Jeg har flere Zipato-installasjoner rundt omkring, og har nettopp fått Tibber i hus.

Er det noen her i forumet som har erfaringer med disse og derfor gode og stabilt fungernde forslag for hvordan jeg kan få Tibber-data inn til Zipato slik at dette kan brukes til strømstyring? 

Jeg bruker ikke Zipato selv, men MQTT skal visstnok støttes. Du kan se litt på om denne kan hjelpe deg videre: https://github.com/iotux/ElWiz

På 13.8.2020 den 21.50, erikolaulvestad skrev:

Forbruket ditt finn du igjen i Elhub. Duger det?

Sent fra min SM-G960F via Tapatalk
 

Er det noen som vet om Ehub har et API? Det blir for bakvendt å laste ned data for en dag om gangen til CSV-fil.

På 13.8.2020 den 11.06, sbarmen skrev:

Har tenkt meg over på en timeavtale men ønsker en leverandør som har gode verktøy for innsikt og oversikt. Kontroll skal jeg lage selv med automatisering, så ikke noe Tibber e.l. Det som jeg ønsker er en leverandør som har rimeligst mulig løsning for å prise per time med en god rapporteringsfunksjon på forbruk per time mot kostnader samt eventuelt anbefalinger ifm det.

 

Jeg merker jeg blir veldig lei av å prate med strømselskaper. Makan til gjeng med lokketilbud skal du lete lenger etter. Er jo skinnjakkeselgere hele gjengen...

Jeg bruker spotprisavtale fra Gudbandsdal Energi. Der betaler jeg bare 9 kr per måned i tillegg til spotprisen. https://www.ge.no/stromavtale/gespotpris

Det er fjerdeparten av det Tibber bregner seg.

For å ha kontroll har jeg laget min egen løsning basert på data fra Tibber Pulse og priser fra den nordiske kraftbørsen. Løsningen min ligger nedlastbar på Github med fyldig dokumentasjon. https://github.com/iotux/ElWiz

Det ligger også noen kommentarer i denne tråden 

ElWiz har nå fått funksjonalitet for å hente priser fra den nordiske kraftbørsen. Programmet for å hente priser heter fetchprices.js og kan brukes uavhengig eller sammen med ElWiz. Det finnes en rekke parametre som kan justeres for tilpasse måten programmet oppfører seg på. For de som bruker Linux vil det være enklest å kjøre det fra cron. Der er imidlertid lagt inn mulighet for å bruke node-schedule for de som ikke har tilgang til cron. Dette styres ved hjelp av et parameter i konfigurasjonsfila. Muligheten for å bruke begge programmene uavhengig av hverandre, styres også av et parameter. Det er gode eksempler i dokumentasjonen.

Ved å kjøre begge programmene sammen, får man i tillegg data som ser slik ut:

{
  "customerPrice": 1.3513, // Lokal valuta
  "lastHourCost": 1.9432,  // Lokal valuta
  "spotPrice": 0.6163,     // Lokal valuta
  "startTime": '2020-08-12T11:00:00',
  "endTime": '2020-08-12T12:00:00'
}

Her får man ferdig utregnet kostnaden per time ut fra forbruk og pris i de forskjellige leddene. I tillegg får man spotprisen tillagt MVA som info. Lokal valuta kan være EUR, DKK, NOK eller SEK. Prisene i de forskjellige sonene kan være svært forskjellig, så det er viktig å konfigurere riktig sone for å få riktige priser.

3 timer siden, teeko skrev:

Endelig fått meg en Tibber Pulse. Den sender rådata til egen Mosquitto MQTT broker etter å ha blitt satt opp som anvist i ElWiz guiden (uten SSL/TLS).

Jeg slo av autentisering i Mosquitto midlertidig - for så langt jeg kan se logger ikke Tibbe Pulse seg på med et brukernavn (?).

 

Antar jeg må sette opp autentisering med sertifikater for at Tibber Pulse skal logge seg på som en bruker?

 

Du trenger ikke nødvendigvis sertifikater med autentisering. Uten sertifikater går trafikken ukryptert. Det kommer an på hvordan du setter opp mosquitto. Jeg håper du har nytte av programmet.

Jeg regner med å utvide med mulighet for å hente spotpriser fra Nordpool. Jeg tester det nå, og bare venter på midnatt for å se hvordan den takler overgangen til nytt døgn. Prisfangsten blir med et annet frittstående program, men delvis integrert. Inkludering av priser blir alikevel sømløst.

Du må gjerne avgi rapport om hvordan det funker for deg. Hvis du bruker annen måler enn Kaifa, vil det også være interessant informasjon.

2 minutter siden, Charlie skrev:

Hos meg sender Tibber Pulse til 52.50.48.219 (ec2-52-50-48-219.eu-west-1.compute.amazonaws.com) på port 8883

Det rimer. Port 8883 er MQTT over SSL. Det kommer også som forslag i web-grensesnittet når Pulse står i AP-modus. Hvis du finner "mqtt_topic_sub", så kan du  prøve "mosquitto_pub -h mqtt_url -t mqtt_topic_sub -m update". Da kan du sniffe hvilken adresse den prøver å oppdatere fra. I ettermiddag har jeg dumpet APKen fra appen vi Linux strings uten å finne noe som ligner topic-string

3 minutter siden, ZoRaC skrev:

Hvis man finner DNS-navnet som Pulse bruker til å kontakte Tibber sin server og oppretter en fake DNS-oppføring som peker den mot samme IP som man selv kjører brokeren på, så kan man sikkert finne ut en del. Litt avhengig av hvordan Pulse håndterer SSL - hvis den kun krever et eller annet sertifikat, så er det jo ingen problem å sette opp lokal broker med SSL på samme port og se hva Pulse sender.  

Jeg tror det er rimelig klart hva Pulse sender. Det er veldig sannsynlig at den sender det samme som ElWiz dekoder. Det som er uklart er hvilken server den sender til og hva som er topics for publisering og abonnering. Jeg er også rimelig sikker på at måler.ID er hele eller del av topic som den sender med for å kunne identifisere kunden/måleren.

Forsøk viser at topic som den abonnerer på sannsynligvis  er bare ett ord. Den gir feilmelding hvis man sender en "kommando" den ikke kjenner. Den sier derimot ikke et kvekk hvis man f.eks. sender pulsecmd/blabla. Ergo abonnerer den bare på "pulsecmd" og ikke "pulsecme/#" eller "pulsecmd/+". Det er naturlig oppførsel  i henhold til protokollen for MQTT. Eksemplet "pulsecmd" er det som vil være lagt inn som "mqtt_topic_sub" i web-grensesnittet. Denne blir etablert ved oppsett av Tibber app og forblir ukjent til noen finner den. Det er heller ikke gitt at den brukes mye. Så langt har jeg bare funnet "reboot" og "update". Det står litt om det her  https://github.com/iotux/ElWiz#styring-av-pulse