Home Assistant - WLANThermo
- Ersteller mfdlr
- Erstellt am
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
Weil das ganze nur 1 Panel ist...
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
Code:
views:
- title: WLANThermo
path: wlanthermo
type: panel
icon: mdi:grill
cards: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
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
Das würde auf jeden Fall Sinn machen mit in die config zu nehmen, sind ja Einstellungen, die man evtl anpassen will.
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.
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.
)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!
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!
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.
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.
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. )
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.
)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.
Den Punkt habe ich mit 0.2.3 gerade umgesetzt. Alle PID-Profile lassen sich jetzt aus HA raus editieren.
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.
Release Pre Release for testing · WLANThermo-nano/homeassistant
Added Push Notification and Bluetooth Configuration
github.com
Neu hinzugekommen sind die Konfiguration von Push Notifications und Bluetooth:
Bluetooth wäre super wenn das andere, vielleicht sogar mit 2-3 Bluetooth Geräten und mehreren Sonden testen könnten.
Ich habe leider nur eins...Wichtig: Wenn Ihr Bluetooth Geräte während des laufenden Betriebs hinzu nehmt, müsst ihr die Integration neu starten. Ich habe nicht herausgefunden wie ich in einem Gerät neue Entitäten Hinzufügen kann, ohne neu starten... Das könnt ihr über "Neu Laden" machen oder den neuen Button.
Achso: falls einer mehr als 2 BT Geräte am Wlanthermo hat (auch 2+ der gleichen Marke), bitte einmal {IPADRESSE}/getbluetooth im Browser aufrufen und json posten. Ich bin mir da mit was unsicher...
Edit:
Ich habe mein Dashboard noch mal nen bisschen aufgebort und gestyled, so wie ich es praktikabel finde.
Will ich euch nicht vorenthalten...
Da es über 2000 Zeichen ist, im Anhang als txt.
Zuletzt bearbeitet:
Am kommenden Freitag müsste ich die Gelegenheit haben, es mit 5 Meater Sonden zu testen
JSON:
{"enabled":true,"devices":[{"name":"MEATER","address":"d0:d9:4f:88:de:ce","count":2,"selected":0},{"name":"MEATER+","address":"b8:1f:5e:30:29:0b","count":6,"selected":0},{"name":"MEATER","address":"d0:d9:4f:88:e4:ff","count":2,"selected":0}]}Edit: wenn ein Device gekoppelt ist, wechselt "selected" auf die Identifizierung der per Häckchen gekoppelten Kanäle des Devices. Die Angabe ist ein Binär-Code: erster Kanal -> erste Stelle: 0 oder 1; zweiter Kanal -> zweite Stelle: 0 oder 1 usw. Beispiel: Kanal 2 und 3 sind ausgewählt: "110" = 6.
Mehr wird über /getbluetooth nicht ausgegeben.
Zuletzt bearbeitet:
Perfekt danke. Ja, den Code wie ihr ch1-6 als selected markiert habe ich rausgefunden, nachdem ich mich erst über 0-72 gewundert hatte.
Lohnt sich wenn man noch C und Bit-Codes kennt. Um die 2+ Geräte zu identifizieren und Kanäle richtig zu zu ordnen, musste ich Namen vergeben. Da die alle gleich heißen, habe ich letzten 6 stellen der Mac genommen, was anscheinend passt.Damit dürfte die Integration wirklich so passen, außer dass ich heute noch einen Bug gefunden habe (wenn Gerät offline, schalten sich manche switches nicht mit aus
). P.S. willkommen zurück aus dem Urlaub
@Moritz82
Ich hatte heute mal etwas Zeit, und habe dein neues Dashbord sowie die Version dev0.3.0 zum testen installiert.
erst mal grosses Lob sieht klasse aus!
Mit meinem Nano gibt es da ein paar Probleme, und Verbesserungsvorschläge.
In den Kacheln zum Pid Profil ist die Beschriftung nicht sichtbar; Bouton funktioniert aber.
Bei Benachrichtigungen und Bluetooth öffnet sich das Fenster, aber die Entitäten werden nicht gefunden, sind nicht vorhanden.
Sollten die automatisch erstellt werden, oder muss man die selber erstellen?
Müssten die ja sein "switch.wlanthermo_bluetooth_0003c9_fuhler_1" und für Benachrichtigungen "x.wlanthermo_push_x_x"
Dann gibt es Entitäten welche erstellt werden, aber nicht verfügbar werden.
Denke bei Servo und PWM ist es so wie bei den ungenutzten Temperatur Kanälen, weil die nicht vorhanden sind.
Aber PID-Profil 1 Aktor-Verknüpfung ist auch nicht Verfügbar, obschon da mein Titan 50x50 angeschlossen und in Betrieb ist
Verbesserungsvorschläge.
1) Wäre es möglich seine selbst vergebenen Kanalnamen in den entsprechenden Kacheln, oder zumindest unter der Grafik anzuzeigen, anstelle Kanal 1 und WLANThermo Kanal 1
Bei mir ist z.b Kanal 9 Meater IN (innen) und Meater AUS (aussen) Ganz ausgeschrieben erlaubt die Wlanthermo App nicht
2) Die Grafik ist im Moment anscheinend fix auf 24 Stunden, eine Möglichkeit um die selber auf die benötigte Länge einzustellen
3) Kacheln werden auf kleineren Bildschirmen (iPad) nicht genug skaliert, werden gestaucht, Diverse Anzeigen abgeschnitten oder überhaupt nicht sichtbar.
4) Rein optisch, schaltet man den Lüfter auf Off wird weiterhin die letzte genutzte Drehzahl angezeigt, und der Lüfter in der Kachel dreht sich weiter.
Ich hatte heute mal etwas Zeit, und habe dein neues Dashbord sowie die Version dev0.3.0 zum testen installiert.
erst mal grosses Lob sieht klasse aus!
Mit meinem Nano gibt es da ein paar Probleme, und Verbesserungsvorschläge.
In den Kacheln zum Pid Profil ist die Beschriftung nicht sichtbar; Bouton funktioniert aber.
Bei Benachrichtigungen und Bluetooth öffnet sich das Fenster, aber die Entitäten werden nicht gefunden, sind nicht vorhanden.
Sollten die automatisch erstellt werden, oder muss man die selber erstellen?
Müssten die ja sein "switch.wlanthermo_bluetooth_0003c9_fuhler_1" und für Benachrichtigungen "x.wlanthermo_push_x_x"
Dann gibt es Entitäten welche erstellt werden, aber nicht verfügbar werden.
Denke bei Servo und PWM ist es so wie bei den ungenutzten Temperatur Kanälen, weil die nicht vorhanden sind.
Aber PID-Profil 1 Aktor-Verknüpfung ist auch nicht Verfügbar, obschon da mein Titan 50x50 angeschlossen und in Betrieb ist
Verbesserungsvorschläge.
1) Wäre es möglich seine selbst vergebenen Kanalnamen in den entsprechenden Kacheln, oder zumindest unter der Grafik anzuzeigen, anstelle Kanal 1 und WLANThermo Kanal 1
Bei mir ist z.b Kanal 9 Meater IN (innen) und Meater AUS (aussen) Ganz ausgeschrieben erlaubt die Wlanthermo App nicht
2) Die Grafik ist im Moment anscheinend fix auf 24 Stunden, eine Möglichkeit um die selber auf die benötigte Länge einzustellen
3) Kacheln werden auf kleineren Bildschirmen (iPad) nicht genug skaliert, werden gestaucht, Diverse Anzeigen abgeschnitten oder überhaupt nicht sichtbar.
4) Rein optisch, schaltet man den Lüfter auf Off wird weiterhin die letzte genutzte Drehzahl angezeigt, und der Lüfter in der Kachel dreht sich weiter.
Zuletzt bearbeitet:
Wenn ich das richtig sehe, bezieht sich das alles auf das Dashboard. Das ist ja nur als Beispiel, besonders das letzte, also "meins" was ich für mich aufgebohrt und farblich gebastelt habe.
Hier sind viele dinge, wie Bluetooth id's ect die man für sich selbst anpassen muss. "0003c9" sind die letzten 6 Zeichen der MAC von meinem Inkbird. Die werden bei dir anders sein.Ich baue meine Kachelnamen auch aus der ID einfach zusammen, wenn du die Namen haben willst, stecken die in "text.wlanthermo_kanal_*_name" und du könntest sie im Dashboard mit
YAML:
wlt_kanal_button:
template: wlt_card_base
variables:
device_name: wlanthermo
show_icon: false
show_name: true
show_state: false
icon: mdi:thermometer
name: |
[[[
const id = parseInt(entity.entity_id.match(/kanal_(\d+)_/)[1]);
const dev = variables.device_name;
return states[`text.${dev}_kanal_${id}_name`]?.state;
]]]Was das ist, ist die Verknüpfung die nur im Damper Fall relevant ist.
Wenn du Damper als Profil aus wählst, hast du den Switch für die Aktor Verknüpfung, bei allen anderen Profilen nicht.
Bei FAN Als Profil stehen dir pwm_maximum und pwm_minimum zur verfügung, nicht aber servo_maximum/servo_minimum und aktor_verknupfung. Läuft also alles wie beabsichtigt.
Edit:
was mir gerade noch eingefallen ist, mit dem Apex Chart hätte ich ne Lösung: Erstelle einen Helfer, um Zeiten zu speichern und einen trigger auf "become_avaible" für den Thermo, der die Zeit setzt. Dann kann APEX das als Zeitspanne nehmen. So ungefähr:
Code:
Helfer:
input_datetime:
wlanthermo_became_available:
name: WLANThermo Became Available
has_date: true
has_time: true
icon: mdi:clock
template:
name: wlanthermo_online_since
unique_id: wlanthermo_online_since
unit_of_measurement: "min"
icon: mdi:clock
availability: >
{{ not is_state('sensor.bbq_thermo', 'unavailable') and (not is_state('sensor.bbq_thermo', 'unknown')) }}
state: "{{ ((as_timestamp(now()) - (state_attr('input_datetime.wlanthermo_became_available','timestamp') | float(0))) / 60) | int }}"
Automatiotion:
trigger:
- platform: state
entity_id: sensor.wlanthermo_gerate_info
from: unavailable
- platform: state
entity_id: sensor.wlanthermo_gerate_info
from: unknown
condition: []
action:
- service: input_datetime.set_datetime
data:
timestamp: '{{ now().timestamp() }}'
target:
entity_id: input_datetime.wlanthermo_became_available
APEX:
type: custom:apexcharts-card
update_interval: 5sec
graph_span: >-
${Math.min(1440, 10 +
parseInt(states['sensor.wlanthermo_online_since'].state) ||
0) + 'min'}
Zuletzt bearbeitet:
nene, dafür ist es zu bunt.Ok danke.
Ging davon aus dass das, das Dachbord wird welches, später zur offiziellen WlanThermo HA Integration dazugehört.
Namen werden mit den Codezeilen übernommen
Naja, dunkel... Ich habe für mich da einfach bisschen gespielt. Das was ich im Repo Pflege ist da etwas zweckgebundener. Aber sowas wie "Namen statt Nummern" für die Kanäle kann man gut übernehmen. Macht ja sinn.