search

ohAnd / dtuGateway

arduino gateway for Hoymiles HMS-800W-2T and similar as stable connection to the dtu for applications in smarthome or IFTT environments with display support OLED/ TFT - available for ESP32 and ESP8266
Apache License 2.0
29 stars 7 forks source link

FeatureRequest: MQTT-Auto-Discovery for Home Assitant #22

Closed ohAnd closed 5 months ago

ohAnd commented 5 months ago 
          Hallo Andreas, ist für Home Assistant auch eine MQTT-Auto-Discovery geplant und eine Visualisierung für ein OLED SSD1306 Display? Das wurde für die HM/HMS ohne W ja schon sehr gut umgesetzt: https://github.com/tbnobody/OpenDTU

LG, Daniel

Originally posted by @smarthomehomebase in https://github.com/ohAnd/dtuGateway/issues/11#issuecomment-2127039724

ohAnd commented 5 months ago

Hi @smarthomehomebase ,

kann ich gerne versuchen... Bin aber kein Nutzer von Home Assistant. Daher die Frage, ob Du bzw. alle die dazu beitragen möchten, hier im thread vielleicht die dafür nötigen Infos sammeln könntest, um die notwendigen Anforderungen an das Auto Discovery zusammen zu tragen.

Was ist seitens Home Assistant für das Auto Discovery notwendig? Bzw. was wird von einem Sensor/ IOT device erwartet, damit diese entsprechend automatisch erkannt und scheinbar zugeordnet werden kann.

Let's gather the needed data for home assitant mqtt auto discovery and also specify based an this data, how it should/ could be implemented ...

BR

smarthomehomebase commented 5 months ago

Hallo Andreas, ich bin nur Anwender. Mit dem Programmieren kenne ich mich zu wenig aus. Vielleicht wirst da ja aus den Dokus schlauer: https://www.opendtu.solar/firmware/configuration/mqtt_settings/ https://www.home-assistant.io/integrations/mqtt/#mqtt-discovery Das läuft mit Home Assistent und OpenDtu sehr stabil.

Lassa333 commented 5 months ago

Hi Andreas,

ich habe mich in der letzten Zeit viel mit dem Thema „Homeassistant und Auto-Discovery“ beschäftigt. Mit deinen Programmierfähigkeiten könnten wir zum 1. Aufschlag antreten:

Zunächst einmal eine kurze Erklärung des folgenden Vorgehens:

Um die HA-Discovery möglich zu machen, müßen die Werte per MQTT versendet werden. Und dies als JSON-Payload in einem speziell gestalteten Topic. Das Topic muss vorgegeben werden und darf NICHT vom User bearbeitet werden! Wenn das gegeben ist, taucht mit Einschalten der Option ein neuer Sensor in HA mit mehreren „Entitäten“ auftaucht. Diese Entitäten können dann in HA genutzt werden (zur Anzeige, Steuerung, Trigger, etc.):

Topic-Gestaltung: Der Topic-Name muss folgendermaßen aufgebaut werden:

homeassistant/sensor/HoymilesGWxxxxxx/config

Hinweis: “HoymilesGWxxxxx” MUSS ein individueller Parameter sein! Es wäre super, wenn xxxxx durch die letzten 6 Zahlen der MAC-Adresse des ESPs ausgetauscht werden könnte: Das wäre dann ein komplett individuelle Parameter – ich hoffe, dass das keine große Herausforderung für dich darstellt 😉 Für den ersten Aufschlag würde ich mal 123456 (super innovativ – ich weiß) vorschlagen

Gestaltung des Payloads: Dieser muss als serialisierter JSON-Payload übermittelt werden. Und sollte nach dem folgendem (nicht serialisierten) Schema aufgebaut werden:

{ "name":"HM_Gateway_total-energy", "unique_id":"HoymilesGW123456", "state_topic":"homeassistant/sensor/HoymilesGW123456/config", "unit_of_measurement":"kWh" “icon”:“mdi:sine-wave” "device": { "name":"HoymilesGateway", "identifiers":"mymqttdevice01", "manufacturer":"OhAnd", "model":"ESP8266/ESP32", "hw_version":"1.23", "sw_version":"1.5.0039", "configuration_url":”http://192.168.xxx.xxx” }

Hinweis:

Abschließender Hinweis: Wichtig wäre es, dass HA-Discovery aktiv eingeschaltet werden sollte. Sonst gibt es einen „Geister-Sensor“, der zwar angezeigt wird, aber keine Werte liefert. Hierzu könnte folgendes Vorgehen gewählt werden:

Option „Aus“ in der Firmware -> es wird ein leerer Payload gesendet (Damit wird der Sensor in HA gelöscht) Option „An“ in der Firmware -> Payload wird wie o.g. versendet. Der Sensor in HA wird mit Eintreffen des ersten Wertes neu erzeugt und angezeigt

Ich hoffe, ich habe tief genug recherchiert. Und bin schon ganz gespannt auf die erste Testung 😊 Für ev. offen gebliebene Frage stehe ich gern zur Verfügung

LG

ohAnd commented 5 months ago

Hi @Lassa333 ,

super, damit kann ich mal die ersten Versuche wagen.

BR

ohAnd commented 5 months ago

Hi @Lassa333 ,

erster Umfang ist nun "drin". Danke für die gute Erklärung zum Start, nach ein bisschen Recherche habe ich es gleich noch wenig erweitert.

Daher die Bitte mal die ersten Tests durchzuführen. => https://github.com/ohAnd/dtuGateway/actions/runs/9407361930 -> artefacts


{
"name":"hoymilesGW_xxxxx836 grid_U",
"unique_id":"hoymilesGW_xxxxx836_grid_U",
"state_topic":"homeassistant/sensor/hoymilesGW_xxxxx836_grid_U/state",
"unit_of_measurement":"V",
"icon":"mdi:sine-wave",
"device":{
  "name":"HoymilesGateway",
  "identifiers":"mymqttdevice01",
  "manufacturer":"ohAnd",
  "model":"ESP8266/ESP32",
  "hw_version":"1.0",
  "sw_version":"1.6.0_localDev",
  "configuration_url":"http://"}
}

Config über das Webinterface siehe readme. (HAutoDiscoveryON = false / true)

Die Abschaltung bzgl. NULL payload hatte ich im ersten Versuch schon mal drin, schiebe ich später nochmal nach. Hier konnte ich aber zur Logik selbst nicht so richtig was finden. Hätte jetzt spontan angenommen, damit wird die Topic ohne 'retain' im Broker gelöscht und damit wird der HA beim Neustart die Config "vergessen" ... Hier wäre gut wenn wir noch ein paar Infos zusammen bekommen.

BR

Lassa333 commented 5 months ago

Hi Andreas,

danke für deine Mail. Leider habe ich diese erst heute Morgen gelesen – konnte also noch keinen Test machen. Das steht aber für heute Nachmittag auf meiner „to-do-List“. Bin schon super gespannt und werde berichten 😊

Bzgl. Des An/Abschaltens des auto-erkannten Sensors in HA:

Du hast recht mit deiner Vermutung. Durch das Übermitteln eines leeren Payloads wird der auto-erkannte Sensor in HA „gelöscht“. Er taucht erst wieder auf, wenn der Payload (mit einem Wert befüllt) wieder auf dem Topic gesendet wird. Hier ist dann noch die Herausforderung, mit der Option „retain“ richtig umzugehen.

So soll verhindert werden, dass beim Wiederanschalten der Option „HA-Auto-Discovery“ in der Gateway-FW ein „neuer“ Sensor (also eine Doublette) erstellt und der vorherige Sensor in HA verbleibt aber keine Werte mehr bekommt. Das meinte ich mit „Geister-Sensor“

Das Konzept habe ich in einem Video aus den USA gesehen ( MQTT 102: Add Home Assistant Discovery to your Devices (youtube.com) https://www.youtube.com/watch?v=VHiCtZqllU8 ) und fand das sehr elegant! Es wird in Minute 5.30 erklärt, und in Minute 8.30 „live“ demonstriert. In Video-Minute 6.49 gibt der Autor gute Tipps bzgl. Der Option „retain“.

Mit diesen Tipps kann ich mir vorstellen, die HA-Auto-Discovery-Option elegant in die Gateway-FW zu implementierten:

HA-Discovery -> Aus Standart-Einstellung Wer kein HA nutzt, wird sich für diese Option nicht interessieren

HA-Discovery -> An Wert-Payload wird im Topic übermittelt Retain: “false” ????? Sensor erscheint in HA und liefert Werte

HA-Discovery -> Aus Null-Payload wird im Topic übermittelt Retain: „true“ ???? Sensor wird dauerhaft aus HA entfernt

HA-Discovery -> wieder An Wert-Payload wird im Topic übermittlet Retain: “false” ????? Sensor erscheint wieder in HA

HA-Discovery -> wieder Aus Null-Payload wird im Topic übermittlet Retain: “true” ????? Sensor wird wieder dauerhaft aus HA entfernt

Hoffentlich bringt dich damit weiter

BR

Lassa333 commented 5 months ago

Hi Andreas, Hier meine Rückmeldung nach dem ersten Test: es geht in die richtige Richtung! 👌

Zum HAutoDiscoveryON:

Was mir aufgefallen ist:

MQTT-Explorer

Ich denke, dass der Payload noch nicht richtig konfigureirt ist. Wie siehst du das? BR

Lassa333 commented 5 months ago

Hi Andreas,

nach dem ersten Test der Firmware hätte ich folgende Anregung: Homeassistant-Discovery als 3. Option im Einstellungs-Reiter "bindings" (neben "openhab" und "mqtt-publishing").

Dann habe nochmal ein bissel weiter recherchiert. Folgende Seite fasst die Umsetzung des HA-Discovery nochmal schön zusammenfassen: https://resinchemtech.blogspot.com/2023/12/mqtt-auto-discovery.html Weiterhin findet sich dort auch ein Code-Beispiel für die HA-Auto-Discovery eines Device mit 4 Entitäten: https://gist.github.com/Resinchem/ecd86dfb52bd699c79acfa80cd348d7b

Dies halte ich für eine gute Blaupause für das Projekt: Nach Einschalten des HA-Auto-Discovery im Webinterface werden ausgewählte Grid-Werte (z.B. U, dailyEnergy und totalEnergy) per mqtt gepublished. Dies in einem Topic, dass so gestaltet ist, dass ein Homeassistant-Instanz im gleichen Netzwerk diese mqtt-Nachrichten "autodiscovered" kann. Und daraus dann automatisch ein neues Gerät mit 3 Entitäten (U, dailyEnergy und totalEnergy) erzeugt.

Leider übersteigt das meine Fähigkeiten bei weitem - deshalb hoffe ich, dass dich diese Anregungen weiter bringen werden.

BR

ohAnd commented 5 months ago

Hi @Lassa333 ,

danke für die ausführlichen Tests...

Nach einem "deep dive" durch die Infos von ResinChemTech, war der erste Schuss nicht wirklich verkehrt...

Habe es erstmal für die Settings so aufgenommen das im Bereich MQTT HA Autodiscovery eingeschaltet und wieder ausgeschaltet werden kann. D.h. wenn MQTT im Normalzustand eingeschaltet ist, kann auf HA gewechselt werden bzw. zurück. Auswirkung ist dann hier

(ob später dann MQTT Standard und MQTT HA Auto getrennte Pfade werden und damit parallel verfügbar, wäre noch die Frage ... aus "Enduser"-Sicht wird ja nicht ständig zwischen den Varianten gewechselt... würde ich im ersten Moment vermuten ;-) )

Zu deinem Punkt:

Es wurde in HA registriert, das ein neues Geräte aufgetaucht ist, ich konnte dieses aber nicht finden

Was meinst Du damit ... ? (sorry, wie gesagt, bin kein HA user)

Andere offene Fragen für mich: Die eigentliche state topic würde ich als freien Pfad interpretieren - da ResinChemTech hier unabhängig von /homeassistant/ ... / ... auf einen eigenen Pfad /state/.../... referenziert - in anderen Beispielen habe ich eben diesen Ansatz mit .../config parallel zu .../state gesehen. Finde ich von der Struktur her auch sinnvoll, um viele Querreferenzen zu vermeiden. Daher die Frage, ob hier eine HA seitige spezielle Anforderung an den state topic Pfad besteht - konnte dazu nichts finden?

Weiterer Punkt zum Löschen ... aktuell würden jetzt die Config Messages gelöscht, ich denke für die Auto-Config im HA ausreichend - ob aber auch die bestehenden state topics gelöscht werden sollen, wäre für mich offen. Durch das "Retaining" bleiben die danach ja im Broker stehen.

nochmal zur config json - sieht nun aktuell so aus, als Beispiel:

{
"name":"Grid power",
"unique_id":"dtuGateway_12345678_grid_P",
"state_topic":"homeassistant/sensor/dtuGateway_12345678_grid_P/state",
"unit_of_measurement":"W",
"icon":"mdi:sine-wave",
"device": {
  "name":"Hoymiles dtuGateway_12345678",
  "identifiers":"dtuGateway_12345678",
  "manufacturer":"ohAnd",
  "model":"ESP8266/ESP32",
  "hw_version":"1.0",
  "sw_version":"1.6.0_localDev",
  "configuration_url":"http://dtuGateway_12345678"
  }
}

Gruss

btw. aktueller feature snapshot -> dtuGateway_snapshot_1.6.0019_22-featurerequest-mqtt-auto-discovery-for-home-assitant.bin

Lassa333 commented 5 months ago

Hi Andreas,

auf den ersten Blick sieht der neuste Snapshot super aus!

Das Auto-Discovery scheint zu funktionieren:

Nach Aktivierung der Funktion in der Firmware erfolgt eine "Benachrichtigung" in HA, dass ein neues Gerät im Netzwerk endteckt wurde

HA-AD1

Beim Klick auf "Check ist out" kommt man auf eine Übersichtseite. In dieser findet sich im Reiter MQTT 1 neues Gerät:

HA-AD2 0

Hier nochmal im Detail

HA-AD2

Nach klickt auf "1 Gerät" kommt man auf die Übersichtsseite des Gerätes, das nun alle Sachen Anzeigt: Geräteinfos, Werte, usw. Das ist neu und genau so, wie es mir vorgeschwebt ist 👌👌👌👌👌

HA-AD3

Es wäre super, wenn andere Homeassistant-User diesen Zwischenstand ebenso verifizieren könnten. Ich werde über den Tag das Release beobachten und noch Auffälligkeiten sammeln.

Insgesamt aber denke ich, dass du das Thema auf einen prima Weg gebracht hast und das Ziel schon langsam am Horizont auftaucht 😊

Lassa333 commented 5 months ago

Hi Andreas,

Zu deine Fragen:

Gibt es HA seitige spezielle Anforderung an den state topic Pfad?

So viel ich weiß nicht - Lediglich fürs AutoDiscover. Normalerweise muss der Pfad in HA zum Topic passened hinterlegt werden [das ist nicht so ganz ohne!!!]. Und das wird ja vom Gerät gepublished. Hier scheint HA sich möglichst "quelloffen" verhalten zu wollen

Weiterer Punkt zum Löschen ... aktuell würden jetzt die Config Messages gelöscht. Sollen auch die bestehenden state topics gelöscht werden?

Wenn das möglich ist, sollte das im kommenden Snapshot versucht werden. Im aktuellen führte ein Abschalten des AutoDiscover dazu, dass das Gerät keine Werte mehr aktualisiert - ab weiter vorhanden ist ("Geister-Gerät"). Wenn durch das Löschen des state-topics das Gerät aus HA entfernt wird, wären wir wieder einen Schritt weiter 😉

Sollen MQTT Standard und MQTT HA Auto getrennte Pfade gehen?

Das wäre aus meiner Sicht super. Dann wäre auch das Gateway "quelloffen": Die User können dann frei entscheiden, ob sie die Werte in

Dinge, die mir im letzten Snapshot (1.6.0019_22) aufgefallen sind:

"device_class": "timestamp", "value_template": "{{ as_datetime(value) }}",

Quelle: https://www.home-assistant.io/integrations/sensor.mqtt/

1) Die Werte für "name" und "identifiers" werden nicht angezeigt. Möglicherweise stößt hier der Payload an die max. Größen-Begrenzung. Das ist ein Flaschenhals des ESP8266. Im Video von ResinTech wurde darauf hingewiesen. 2) Die IP wird als Link "besuchen" aufgelöst. Ich fände es schick, wenn hier die IP als Verlinkung zur FW-Seite stehen würde

Deve-Beschreibung

denkandich commented 5 months ago

Hallo,

woher bekomme ich diesen Snapshot zum testen ?.

Lassa333 commented 5 months ago

@denkandich:

dieser Link: https://github.com/ohAnd/dtuGateway/actions/runs/9432311667 führt dich auf eine Seite. Dort im unteren Teil rechts findest du ein Download-Icon

snapshot

Da bekommst du die Snapshot-FW 1.6.0019_22

denkandich commented 5 months ago

Danke, das muss man erst mal wissen und dann finden, ich teste die Version.

denkandich commented 5 months ago

So der erste Test, bei mir funktioniert der MQTT nicht. Wenn ich auf die letzte Stable gehe, bekomme ich die Daten im MQTT Explorer, aber nicht im HA. Wenn ich auf den letzten normalen Snapshot gehe, geht es auch nicht, es kommen keinen Daten mehr im MQTT Explorer an. Gehe ich zurück auf die letzte Stable kommen die Daten wieder im MQTT Explorer. Also hilft mir dieser neueste Snapshot nicht, da nichts ankommt. Den HAutoDiscoveryON habe ich auf true gesetzt, aber wenn schon im MQTT Explorer nichts ankommt bringt mir das nichts.

Lassa333 commented 5 months ago

Du hast die Version 1.6.0019_22 aktiv?

Bei der Version kannst du wieder (wie gewohnt) über die Einstellungen arbeiten. Versuch doch bitte mal folgendes:

in der Firmware: Unter Einstellungen -> bindings ganz runter scrollen und den Haken bei "Homeassistant Auto discovery" setzten. Speichern.

Bekommst du nun deinem Homeassistant eine neue Benachrichtigung, dass ein neues Gerät entdeckt wurde?

denkandich commented 5 months ago

Unglaublich aber wahr, hatte die 1.6.0018_22 drauf und ging nicht, jetzt schreibst du von der 1.60019_22, habe noch mal die Artefakte geladen und da kam jetzt die 1.6.0019_22. Auf die Box und jetzt geht es, habe jetzt 4 Geräte im MQTT und konnte die Werte hinzufügen. Sind 19 Stück, was für eine Entwicklung. Muss mich mal ganz ganz herzlich für die Unterstützung bedanken, ist eine tolle Leistung was ihr hier macht. Danke

Lassa333 commented 5 months ago

😊 Super, dass es nun bei dir auch geklappt hat! 👍👍👍👍👍

Nur zur Rückbestätigung: Du hast lediglich den Haken gesetzt, keine sonstigen MQTT-Einstellungen in der FW gemacht?

denkandich commented 5 months ago

Hallo, habe nur den Haken Home Assistant Auto Discovery gemacht, sonst nichts. Die IP und der Port waren richtig, der User und das PW auch, und die main topic war bei mir auch noch auf HMS800.

Lassa333 commented 5 months ago

OK. Kannst du bitte mal im MQTT-Explorer in HA nachschauen, über welchen Topic die Werte bei dir reinkommen? Über den Topic "HMS800" oder über den Topic "homeassistant/sensor/hoymilesGW_xxxx...."?

denkandich commented 5 months ago

Hallo, das ist lustig, ich dachte es kommt nichts mehr im MQTT Explorer an, aber du hattest recht vorher kam es immer entweder mit dtu1 oder HMS800 an, jetzt kommt es als homeassistant/sensor/hoymilesGW_1899989 an. So ist es auch im MQTT im HA drin: Hoymiles dtuGateway_1899989. Hoffe konnte helfen.

Lassa333 commented 5 months ago

Prima, die Info hilft echt weiter!

Sie zeigt, dass sich die FW-Version bei uns beiden gleich verhält! Und dass der HA-AutoDiscover grundsätzlich zu klappen scheint.

ohAnd commented 5 months ago

@denkandich schön das es nun funktioniert hat, daher gerne auch das Update noch mal testen

@Lassa333 super, danke für das Feedback...

Um es auch für mich verständlicher zu machen habe ich mir eine Virtualisierung von HA in "leer" erstellt ;-) - ist ja aufgrund guter Doku sehr einfach. Damit konnte ich deine beschriebenen Fälle nachvollziehen. Und auch einen Fehler entdecken, den ich erstmal so von ResinChemTech übernommen hatte ... Die null-Payload wird mit seiner Lösung scheinbar nicht korrekt erzeugt zumindest für meine Mosquitto Instanz... Daher im aktuellen Stand (siehe letzter Branch Build unter "Actions") gefixt => An- / Abschalten erzeugt den Sensor und nimmt ihn auch wieder aus HA heraus.

Die Config Daten bzgl. Timestamp habe ich mal versucht - komme aber mit device_class = "timestamp" und dem template an keine andere Darstellung in HA erreichen ... - hier braucht es wohl noch ein wenig Recherche ...

Aber, in dem Zuge habe ich die Icons und device-classes gleich noch Wert-spezifisch gesetzt - passt dann hoffentlich für eine gute automatische Grundeinrichtung. (btw. Diesen Teil wird ich fix im Code lassen. Also eben nicht auch noch konfigurierbar, da die automatische Konfiguration eben ein gute Grundlage stellen sollte, die nicht auch zu konfigurieren sein sollte.)

Bzgl. Daten des Devices ... es wird scheinbar nicht mehr "gerendert" - aber ich denke das passt auch so... das alle Daten kommen und nicht der ESP hier was "falsch" macht, kannst du bei "BESUCHEN" -> 3 Punkte -> "MQTT Info" sehen.

Der Link zur FW Seite funktioniert nun auch.

offen: Zu state topic Pfaden bzw. zu den Varianten die seitens User an-/abgeschaltet werden könnten ... Bin hier immer Fan von Generik - d.h. aus meiner Sicht bauen die verschiedenen Themen aufeinander auf. D.h. wäre mein aktueller Ansatz

  1. grundsätzlich MQTT ja/ nein (d.h. IP/ port/ user / pass)
  2. damit minimal notwendig der state topic Basis-Pfad
  3. HA Auto Discovery ja/ nein (mit oben beschriebenen Verhalten) Damit wäre dann für AutoDiscovery der gleiche state topic Pfad möglich, wie auch ohne, also für Standard MQTT Einsatz. Was ich mir noch nicht zu Ende überlegt habe ... wenn der vom User genannte Topic durch ein 2. Gerät in derselben Umgebung identisch gesetzt wird, dann gibt es zwar 2 unique Entities im HA aber die referenzieren dann auf die gleichen state topics ... Da war meine erste Idee, um es zuletzt auch einfach zu halten, es gibt eine default base topic die gleich "dtuGateway_<12345678>" also entsprechend chipID damit einzigartig wird. Was meinst Du?

Gruss

Lassa333 commented 5 months ago

Hi, na dann: Herzlich willkommen im Kreise der HA-User 😁 Vielleicht kannst du mir ja mal berichten, was die grundlegenden Unterschiede zu openhub sind. Und ob HA an openhub heranreicht

Leider reicht die bei mir Sonne nicht mehr, um die FW komplett zu "ergründen" - Aber was ich bis jetzt gesehen habe sieht SUPER aus!!! 🤩🤩🤩🤩

Hier mal meine erste Rückmeldung:

Zu dem "generischen" Ansatz: Ich bin nicht sicher, ob ich alles so verstanden habe, wie du es meinst. Jedoch möchte ich zu bedenken geben, dass dann das Topic (für die reine MQTT-Verbindung) sehr lang und komplex wird. Denn um autodiscovered zu werden, muss es ja definiert aufgebaut sein: <discovery_prefix>/<component>/<object_id>/config Und diese Struktur müßte dann zusätzlich noch "hardcodiert" werden - eine Änderung im Topic-Namen würde das anschließende HA-Auto dann nicht mehr möglich machen. Und ein User muss dann ggf. mit einem Benutzernamen, Paswort und einem sehr langen Topic-Namen umgehen. Oder kann diesen u.U. nicht nach seinen Vorstellngen anpassen

Deshalb würde ich eher dazu tendieren, MQTT und HA-Autodiscover von einander zu trennen - sprich 1 frei wählbares (für Standard-MQTT) und ein hardcodiertes (für HA-autodisvoer) Topic vorsehen

Soweit meine Gedanken dazu.

BR

ohAnd commented 5 months ago

Hi @Lassa333 ,

hab mal die Variante mit gleicher Topic Path für mit und ohne HA implementiert - zum Testen: Heisst: die "mqtt main topic for this dtu" wird für den Standardfall wie bisher genutzt, gilt aber auch als root für die "states" in der HA AutoDiscovery Config. D.h. in der config wird dann direkt auf den state z.B. "state_topic":"dtu1/inverter/WifiRSSI" referenziert. D.h. die Funktion in HA ist damit genauso gegeben und wenn ich HA abschalte, werden die config gelöscht, Gerät verschwindet aus HA und die states werden nur für die Normalverwendung, weiter und ohne Unterbrechung bereitgestellt. (Und im MQTT explorer o.ä. ist es einfacher lesbar.)

Das meinte ich oben ;-)

Gerne mal anschauen -> https://github.com/ohAnd/dtuGateway/actions/runs/9455482339

BR

Lassa333 commented 5 months ago

Hi Andreas,

in der Zwischenzeit hatte ich nochmal ein bissel Zeit, die FW zu testen. Hier meine Eindrücke:

unix time

Sollte das ein zu großer Aufwand werden, würde ich ggf. auch auf den Wert verzichten - das ist jetzt schon "Arbeiten im µ-Bereich" 😉

ohAnd commented 5 months ago

Hi @Lassa333

das Thema mit dem Timestamp ist nun auch in Ordnung. Hier gibt es ein nicht ganz so nachvollziehbares Verhalten von HA bzgl. was darf noch übermitteln werden und in welcher Reihenfolge im JSON (?), hier nur bzgl. der device_class 'timestamp' . Habe verschiedene Varianten geprüft, bis dann die Aktuelle zum Erfolg geführt hat.

Zum Finale ist nun auch das PowerLimit Setting über MQTT (incl. HA configure) möglich. D.h. es wird eine Topic (siehe Readme) subscribed auf valide Werte geprüft und an die DTU gegeben, um z.B. dynamsich das Powerlimit von 2 - 100 % anpassen zu können.

D.h. das wäre nun der Stand auf dem Weg zum Snapshot und Release.

Gerne nochmal Feedback/ Testen, dann können wir das Thema schliessen.

@denkandich gerne auch noch eine weitere Meinung ;-)

BR

feature snapshot => artefact/ download

Lassa333 commented 5 months ago

Hi Andreas,

ich habe gestern noch die FW aktualisiert. Meine Eindrücke:

Wenn du da nochmal ran möchtest, hier wäre ev. ein Ansatz um °F in °C schon im payload umzurechnen:

value_template: '{{ "%.2f"|format((( states("sensor.sensor_up_hall_temperature_air") | float ) -32) *5/9) }}'

Ansonsten denke ich, das Feature ist erfolgreich implementiert: Erneut großes Lob für Deine schnell und Nachhaltige Umsetzung 👌👌👌👌

ohAnd commented 5 months ago

@Lassa333 danke fürs Feedback... Das Temperatur-Thema kann ich nicht direkt nachvollziehen... Kommt bei mir als Celsius von der DTU und wird demnach auf Webseite und HA als Celsius angezeigt.

image

Daher die Frage was siehst du auf der Webseite? Wüsste auch spontan nicht, ob man irgendwo die Einheit in der DTU konfigurieren könnte...

Sind deine lokalen Einstellungen im HA vielleicht auf imperial?

Lassa333 commented 5 months ago

Hi Andreas, Du hattest recht: ich hatte (nach dem letzten Neuaufsetzen) HA noch nicht auf °C umgestellt.

Naja, zumindest kann ich jetzt auch bestätigen, dass auch das Umstellen im Entitäten Menü geht. Somit ist global °C und für das Gateway auch °F in der Anzeige möglich ;)

Also, von meiner Seite ist die FW Version super so wie sie jetzt ist. Mit Deinem generischen Ansatz hab ich zwar noch nicht komplett Frieden geschlossen :) , aber aus meiner Sicht könnte dieser Stand gerne so in den kommenden Verdionsupdate übernommen werden!

BR