Home Assistant - WLANThermo

Das ist schon nen Unterschied zu meinemauf den ersten Blick. Sind die beim Gerät dann 0, unknown oder not available?
Fehler liegt auf jeden Fall in der sensor.py. funktionieren andere Werte wie min/max?
Die Json muss ich mir am PC ansehen, das bekomme ich am Handy nicht hin.

Der Wert wird als unknown angezeigt

Ok, das weißt auf jeden Fall drauf hin, dass er den gar nicht ließt aus dem Json oder das Parsen fehlschlägt. Wenn du Lust hast, lösch in der sensor.py die Zeilen 120-122, das setzt die auf unavailable, wenn 999°. War das einzige was ich da geändert habe. Dann device neu laden. Werde mir das aber in Ruhe noch mal ansehen und versuchen, nen nano und Link zum testen zu bekommen. Mir gefällt die Integration mittlerweile besser als mqtt, obwohl ich noch einiges Arbeit reinstecken muss, bis ich Farben, Alarme ect wieder habe, wie in mqtt


Ähm, hast du beide Integrationen parallel laufen? Kannst du die originale löschen, dann neu starten, meine hinzufügen und device als nanov3 anlegen? Nur um sicher zu sein, dass wir auf die richtigen schauen...

Ok, die beiden Zeilen habe ich gelöscht.
Das Resultat ist sehr komisch. Jetzt wird bei den Kanälen 1-8 immer noch unknown angezeigt, dann die richtige Temperatur bei 9 und 10 was bei mit der Meater ist, 11 -12 wieder unknown.
Dann gibt es unknown Temperature Sensoren die eine Temperatur anzeigen z.b. der erste sensor.nano_fisch_temperature mit 21,3 Grad was dem Kanal 2 in der WlanThermo App ensprechen würde

Ich habe jetzt mal deine sensor.py durch die Original von lemuba ersetzt. Alle Sensoren zeigen die richtige Temperatur.
Wenn ich die beiden sensor.py miteinander vergleiche, gibt es schon so einige Unterschiede, das ist aber absolut nicht mein Gebiet um zu sagen was da der Fehler ist.
Ich habe noch versuchshalber die 3 Zeilen die ich löschen sollte, in die jetzige sensor.py an die entsprechende Stelle jetzt 118 bis 120 eingesetzt. Da reicht aber nicht aus um die 999 nicht mehr anzuzeigen, hingegen werden aber weiter die richtigen Temperaturen, und wo kein Sensor ist 999 angezeigt. Was aber sowieso kein grosses Problem darstellt, im Dashboard lässt das sich mit einer Bedingung ja einfach ausblenden.

Diese Version gefällt mir auch besser als die MQTT Variante, wenn du also weiter Änderungen vornimmst stell sie bitte wieder hier rein. Danke im Voraus.

Vielen Dank für's testen! Ja es ist wie ich vermutet habe, werde morgen mal auf der Arbeit schauen, wo ich es kaputt gemacht habe. Ich hasse Python. Aber danke deinem testen, bekomme ich das schnell gefixed und werde auf jeden Fall mir auch einen nano und Link organisieren. Dann brauche ich nur noch 2 Grills, damit die Verwendung haben.
Edith:
So, anstelle die HA integration zu erweitern, für alle sensoren die mir fehlten, habe ich die einmal komplett neu geschrieben. Betatesting gerne gesehen, damit es zum Sommer rund läuft!

So, ich habe die Woche viel getestet und mich mit @s.ochs ausgetauscht. Herausgekommen ist dabei eine Integration für Home Assistent, die nach aktuellem Stand alle Sensoren, pitmaster, Einstellungen von allen Varianten mit WebAPI unterstützt.
Nächstes Ziel ist mehr Beta testing und im Februar soll die dann offiziell in hacs gelistet werden.
Daher: wäre super wenn ein paar mehr das noch mal installieren würden und ihre Rückmeldung geben.

Bekannte Bugs:
Zweifaches hinzufügen mit gleichen Namen führt zu fehlern,
Nicht aktive Temperatur Kanäle (kein Fühler) lassen sich evtl nicht updaten,
Wenn ein Kanalname in Weboberfläche gelöscht wurde, erscheint er als unknown in textbox und drop-down für pitmaster

Servus!
Super Integration! Ich hab sie mir ebenfalls direkt installiert und bin begeistert, großes Lob!

Eine kleine Ergänzung:

• Die Temperatur des Pitmaster als eigene Entität wäre noch super. Natürlich geht es auch Template Sensor. Aber alles aus einer Hand (Integration) wäre super.
• Kanal X Temperatur & Temperatur Restzeit: Wert bleibt bestehen statt auf unavailable zu gehen bei ausgeschaltetem WlanThermo

Ein super Usability Upgrade für das WlanThermo Framework!

Na Servas schrieb:

Die Temperatur des Pitmaster als eigene Entität wäre noch super. Natürlich geht es auch Template Sensor. Aber alles aus einer Hand (Integration) wäre super.

Zum Vergrößern anklicken....

Wie meinst du das? Der pitmaster hat ja eigentlich keine Temperatur, sondern ein Temperaturfühler steuert den pitmaster. Daher ist pid 1 = Kanal 9 und das ist die Temperatur, an der sich der pitmaster orientiert zum regeln. Meinst du den Kanal Doppeln, einmal als Kanal 9 temp und einmal als pid1 remp?

Na Servas schrieb:

Kanal X Temperatur & Temperatur Restzeit: Wert bleibt bestehen statt auf unavailable zu gehen bei ausgeschaltetem WlanThermo

Zum Vergrößern anklicken....

mhhh, ja das könnte gut sein. Wenn die API Abfrage fehl schlägt, macht er nichts, versucht es nur x Sekunden später wieder... Da muss ich schauen, wann/wie ich das gesamte Gerät deaktiviere und unavailable mache.

Hab beides allerdings mal aufgenommen. Falls du GitHub Account hast, kannst auch drunter schreiben was du genau meintest.

Moritz82 schrieb:

Meinst du den Kanal Doppeln, einmal als Kanal 9 temp und einmal als pid1 remp?

Zum Vergrößern anklicken....

Aus meiner Sicht: Ideal wäre komplett dynamisch: Man hat ja die Möglichkeit Kanal 1...9 dem Pitmaster zuzuweisen. Diesen Kanal dann auf den Pitmaster kopieren.
Pitmaster_0_Temp = data.channel[data.pitmaster.pm[0].channel].temp

Somit wird bei einer Änderung des Pitmaster Temperaturkanal direkt die Pitmastertemperatur auf den anderen Kanal mitübernommen.

Moritz82 schrieb:

Da muss ich schauen, wann/wie ich das gesamte Gerät deaktiviere und unavailable mache.

Zum Vergrößern anklicken....

Machst du das bei den Konfig Entitäten anders? Bei denen funktioniert das tadellos.

Ja, Kanal 9 war jetzt nur Beispiel, weil ich den darauf gerade habe durch den Typ K der eingesteckt ist. Ich sehe das Problem, dass man ja 2 temp Sensoren hat die die gleiche temp anzeigen. Hab es als Feature aufgenommen.

Na Servas schrieb:

.Machst du das bei den Konfig Entitäten anders? Bei denen funktioniert das tadellos.

Zum Vergrößern anklicken....

Jup, ist ein wenig anderes Error Handling, aber sehe ich mir Donnerstag an.

@Moritz82 vielen Dank für deine tolle Arbeit mit der Integration!