Home Assistant - WLANThermo

[Voxid]

 

[Moritz82]

da ist schon nen unterschied:
Titel: Home ist nicht meine erste Zeile, sondern button_card_templates:
Also alles!!!! löschen und dann nur meinen code da rein. Ich wette weiter unten ist noch mehr deadcode was die ansicht komplett zerstört.
irgendwo in zeile 460 steht auch

views:
  - title: WLANThermo
    path: wlanthermo
    type: panel
    icon: mdi:grill
    cards:

Weil das ganze nur 1 Panel ist...

 

[Voxid]

Und schon geht's. Vielen Dank!

 

[Moritz82]

Dann gibt mal Rückmeldung wie es ist, ob sich alles gut einfügt und sie CH intuitiv bedienen lässt

 

[Na Servas]

Servus,

ein Punkt, welchen man auch noch andenken könnte, allerdings evtl nicht sein muss:
In der API gibt es die Einstellungen zum Pitmaster: GET /sttings/pid[X] die Punkt DCmmin und DCmmax. Also die max. und minamalen Duty Cycle für den Pitmaster.
In der Entität "number.wlanthermo_pitmaster_1_leistung" sind diese als Attribute angeführt, werden allerdings nur mit 0 & 100 initialisiert.
Richtig cool wäre es, wenn die Grenzen für die Pitmasterleistung aus der API übernommen werden würden.



Eine zweite Idee:
Für die Temperaturkanaäle das Attribut "high alarm active" und "low alarm active" einführen, welche den Alarmzustand repräsentieren. Man könnte davon auch eine Entität ableiten, welche die Alarme bündelt und bitweise darstellt.
z.B.: Entität für die obere Temraturgrenze
high_alarms_active = [0000 0000 0000 0000] => kein Kanal über seiner max temp
high_alarms_active = [0000 0000 0000 0001] => kein Kanal 0 über seiner max temp
high_alarms_active = [0000 0000 0000 0010] => kein Kanal 1 über seiner max temp
high_alarms_active = [0000 0000 0001 0011] => kein Kanal 0 & 1 & 4 über deren max temp

Eine (einzelne) Automation zur Überwachung der kanalgrenzen könnte man so einfach erstellen.


Just my 2 cents
Meine kreativen Ideen beim Testen und einbauen der Integration

 

[Moritz82]

In der API gibt es die Einstellungen zum Pitmaster: GET /sttings/pid[X] die Punkt DCmmin und DCmmax. Also die max. und minamalen Duty Cycle für den Pitmaster.

Das würde auf jeden Fall Sinn machen mit in die config zu nehmen, sind ja Einstellungen, die man evtl anpassen will.

In der Entität "number.wlanthermo_pitmaster_1_leistung" sind diese als Attribute angeführt, werden allerdings nur mit 0 & 100 initialisiert.

Das verwechselt du glaube ich. Die min/max sind die Attribute von was bis was sich der Lüfter regeln lässt. Daher wäre dCmmin zwar ähnlich zu min, aber damit ich nicht der Minimum DCmmin in den pitmaster Einstellungen gemeint, sondern nur die numerische Begrenzung des Sensors.

Für die Temperaturkanaäle das Attribut "high alarm active" und "low alarm active" einführen, welche den Alarmzustand repräsentieren.

Das wiederrum denke ich ist zu spezifisch für automatisierungen und ist in der Automatisierung über nen min/max wert besser zu realisieren, als in der Integration. Es ist ja auch kein wert, den der Thermo eigentlich zur Verfügung stellt. (Ok, Restzeit auch nicht, den habe ich mir eingebaut, weil ich ihn aus der mqqt Integration kenne und lieben gelernt habe. )

 

[EddyCH]

Ich verstehe die Details, die ihr hier diskutiert zwar nicht. Aber super, dass ihr das macht. Darum möchte ich euch einfach nur "Danke" sagen!

Für mich ist es eine Vereinfachung. Ich habe am BigJoe noch ein iKamand in Betrieb, der mit dem Homeassistant noch steuerbar ist. Und am "kleineren" KamadoJoe Classic den Wlanthermo. So kann ich alles übersichtlich an einem Ort zusammenbringen.

Einfach Top! Danke nochmals!

 

[Albert64]

Mir ist eben ein Fehler aufgefallen der sich bei der Version 0.2.2 eingeschlichen hat (zumindest für Nano V3)
Im Pitmaster PID-Profil wird nicht mehr SSR; SousVide, Titan 50x50 .... angezeigt

sondern; Profile 0, Profile 1 und Profile 3
Das wird so aber nicht vom WlanThermo Nano V3 erkannt.

 

[Moritz82]

Ich habe gerade nur den Mini V3 ESP32 an, der ist aber gleich und hier habe ich

0/1/2 ist eigentlich nen FallBack wenn er die Pid settings nicht abrufen kann. Sehe ich mir aber zuhause noch mal an, was der Mini V3. Ich baue da gerade eh um, um PID Profile editierbar zu machen. Lösche aber bitte mal dein Log und Thermo aus HA, füge dann neu ein und schau im Log ob da "
WLANThermo: Failed to extract sensor type names as objects: {e}. Trying dict fallback." steht oder "
WLANThermo: No sensor types found in settings.sensors. Using fallback types."
Beides ist unmittelbar vor Pid Profil Namen (hat leider keinen eigenen Error. )

 

[Albert64]

Lösche aber bitte mal dein Thermo aus HA, füge dann neu ein

Das hat gereicht um den Fehler zu beheben.
Vorher hatte ich schon ein paar mal das WlanThermo neu gestartet, was den Fehler aber nicht behoben hatte.

 

[Moritz82]

Ja ich nehme es in die Bug Liste auf. Vieles Lade ich nach, wenn möglich. Die pid Profile aber noch nicht... Da ich die config aber gerade baue löst sich das später vielleicht

 

[Moritz82]

Servus,

ein Punkt, welchen man auch noch andenken könnte, allerdings evtl nicht sein muss:
In der API gibt es die Einstellungen zum Pitmaster: GET /sttings/pid[X] die Punkt DCmmin und DCmmax. Also die max. und minamalen Duty Cycle für den Pitmaster.

Den Punkt habe ich mit 0.2.3 gerade umgesetzt. Alle PID-Profile lassen sich jetzt aus HA raus editieren.

Mir ist eben ein Fehler aufgefallen der sich bei der Version 0.2.2 eingeschlichen hat (zumindest für Nano V3)
Im Pitmaster PID-Profil wird nicht mehr SSR; SousVide, Titan 50x50 .... angezeigt sondern; Profile 0, Profile 1 und Profile 3

Den sollten wir jetzt auch gefixed haben, da ich nicht mehr am Anfang die Profil(-Namen) lade, sondern die gesamten Profile Dynamisch lade und editierbar gemacht habe.

Donnerstag kommt mein BL -Thermometer, dann kann ich testen ob das auch zuverlässig klappt.