SONOFF NSPanel mit Lovelace UI
-
Etwa so (siehe Zeile 8 und 11)
{ "_id": "alias.0.Kontaktsensoren.Garage.ACTUAL", "native": {}, "type": "state", "common": { "alias": { "id": "0_userdata.0.Test.Garage.ACTUAL", "read": "!val" }, "name": "ACTUAL", "role": "switch.gate", "type": "boolean", "unit": "" }, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1666778647324 }Dann würde die Logik für das Script gleich bleiben und auch in der cardEntities funktionieren
-
Genau so hatte ich das gerade schon umgesetzt.
Gefällt mir so am besten, da ich dann im Skript kein externes Wissen mehr brauche
-
Die Variante hätte ich ebenfalls gewählt.EDIT: Obwohl wenn ich mir die Post's ansehe, dann würde es dir glaube ich nicht schwer fallen, die ein oder andere Lösung für das TS-Script weiterzuentwickeln
Gerne auch per "Pull request"
-
Und noch ein paar Verständnisfragen zur Thermostat-Karte.
Wenn ich das in Deinem Beispiel richtig sehe, nutzt Du ein Homeatic Thermostat.
- Liefert der für LOWBAT direkt boolean Werte? Meine tado-Thermostat-Ventile liefern hier auf diesem Indicator aktuell einen String mit Value "NORMAL". Wenn ich das im Code richtig sehe, prüfst Du hier direkt auf boolean-Werte. Ich müsste mir dann hier entweder im DP das ganze convertieren oder auch einen userdata DP anlegen, korrekt?
- In der Karte sehe ich unter der aktuellen Termperatur den Zustand, der aktuell auf MANU steht (habe noch keine DP unter userdata definiert). Ich vermute mal, dass es genau daran liegt (und dass es auch noch keine Skripte gibt, die diese DP als boolean Werte befüllen).
-
Ja, die HomaticIP-Thermostate kennen nur die Zustände Batterie (true/false)
-
Die Visualisierung des Indikators kennt nur zwei Zustände und ein z.B. Normal könnten wir nicht unterbringen. Insofern würde ich ebenfalls eine Umwandlung beim Lesen auf den boolschen Wert im ALIAS vornehmen --> Wenn "NORMAL" dann false.
-
Bei der Nutzung von direkten "Mode's" müssen die Datenpunkte angelegt und eine entsprechende Verknüpfung im ALIAS erfolgen. Danach schaltet das Panel die Datenpunkte. Ein externes Skript macht dann die restliche Verarbeitung.
-
-
Alles klar, dann habe ich das korrekt verstanden und eingebaut.
Allerdings scheint der VACATION Modus nicht sauber zu funktionieren.Ich habe aktuell drei DP: AUTOMATIC, LOWBAT und VACATION
AUTOMATIC true/false klappt ohne Probleme
LOWBAT auch
Wenn mein Script allerdings den DP VACATION auf true setzt, dann komme ich aus dem Screensaver nicht mehr heraus. Erst wenn der Wert wieder false im DP ist, komme ich aus dem Screensaver heraus. Im Code sehe ich hier allerdings keinen Fehler. -
Kannst du mal senden, was an das Panel gesendet wird? mqtt.0....CustomSend wenn die Seite aufgerufen wird?
-
Bein Abfallkalender wird im Skript bei Farbe z.B.: Color = 2016 angegeben oder Color = 33840.
Was ist das für eine Codierung? Wie finde ich da raus welche Nummer welche Farbe ist?
-
@gre4t0ne sagte in SONOFF NSPanel mit Lovelace UI:
2016
RGB565 ist das... mit dem das Nextion-Display arbeitet.
Um herauszufinden, welche Farbe der Dezimal-Code hat kannst du:
https://nodtem66.github.io/nextion-hmi-color-convert/index.html
verwenden -
pageType~cardThermo entityUpd~Heizung Arbeitszimmer~0|1~alias.0.Beutelsend.Dachgeschoss.Arbeitszimmer.Heizung~26.1°C~190~AUTO~50~250~5~~65222~1~AUTT~~33840~1~VACT~~2016~1~HUM~~2016~1~LBAT~~~~~~~~~~~~~~~~~Aktuell~Zustand~~°C~~ time~17:43 pageType~screensaver color~0~65535~65535~65535~65504~65535~65535~65535~65535~65535~38066~38066~38066~38066~65535~65535~65535~65535~65535~65535~65535~65535 weatherUpdate~~19.9 °C~Do~~20.9 °C~Fr~~23.3 °C~Sa~~22.2 °C~So~~21.4 °C~~~~64512~~64512~Und im JS-Log:
script.js.bag-end.nspanel.NSPANEL_1_3_5_0: function GenerateThermoPage: Cannot read properties of null (reading 'toFixed') script.js.bag-end.nspanel.NSPANEL_1_3_5_0: function SendToPanel: Cannot read properties of undefined (reading 'payload') -
@armilar lol den kannte ich nicht, da hätt ich den in meiner Doku ja gar nicht bauen müssen ...
-
stimmt, der macht schon alles
-
Der entityUpd String ist schonmal okay. Der läuft bei mir auch in Interaktion mit der Tasmota-Konsole einwandfrei.
Die einzige Stelle für einen toFixed ist beim Setpoint. Das ist also der .SET
Was ist das für ein Datentyp, dass der sich so sehr weigert? Ist bei mir number
-
"common": { "name": "SET", "role": "level.temperature", "type": "number", "read": true, "write": true, "alias": { "id": "tado.0.796024.Rooms.5.setting.temperature.celsius" }, "unit": "°C" }Wobei mich das gerade auf eine Idee bringt..
Muss gerade mal kontrollieren, was dort drin steht, wenn die Thermostate auf AWAY sind.// Update: Bei AWAY, welches ich für VACATION nutzen will, ist der SET auf null. Das dürfte das Problem sein. Wird so bei tado vom adapter in den tado DP eingetragen (Zumindest, wenn die Ventile auf Frostschutz dann für AWAY gestellt sind).
-
Na super - top Geräte, aber die Entwickler.... tzzzz
Sollte man dem bei null irgendetwas valides mitgeben. Evtl. eine 15, 16 ode 17?
Gehen die von einer Auto-Steuerung aus?
-
@armilar
Zumindest sehe ich in der tado-App keine Temperatur, wenn ich das Ventil auf Frostschutz stelle.
Lt. DPs ist die kleinste einstellbare Temperatur am Gerät selbst 5°C.In der Praxis dürfte hier ein Wert so bei 15°C wahrscheinlich besser sein.
Was ist hier der Plan? Einen Null-Check ins Skript einbauen mit einem konfigurierbaren Minimalwert?
Oder auch wieder ein userdata DP, welcher via Script die Lese/Schreib-Aktionen ausführt?// Update:
Was meinst Du mit Auto-Steuerung?Aktuell hab ich die tado-Anlage fertig nach Zeitplänen eingerichtet. Und on Top noch Geofence aktiviert. Damit regelt das System dann runter, wenn niemand daheim ist.
-
ich würde den null - Check nehmen. Gibt vielleicht auch noch andere Thermostate. Die 15 könnte man noch konfigurierbar machen...
-
Ok, dann versuch ich mich mal an einem PR im Script mit dem Null-Check
-
@armilar said in SONOFF NSPanel mit Lovelace UI:
Hi, bin aktuell etwas eingespannt, kann sich heute etwas hinziehen.
Die Tasmota Rule2 ist dafür da, die Buttons als Favoritenseiten zu benutzen. In diesem Zusammenhang werden keine Relays genutzt. Natürlich kann man das auch auftrennen, in dem man eine ButtonPage benutzt und einen physischen Hardware-Button.
Stat ist nur der Status des Buttons - den kannst du über stat nicht verändern. Wenn der POWER1 oder/und POWER2 aktiv gesteuert werden soll, muss dass über cmnd erfolgen.
Ich habe eigentlich nie versucht, einen Thermostaten zu ersetzten, aber ich denke es gibt in diesem Topic bereits den einen oder anderen, der dass bereits realisiert hat.
Von meiner Seite aus müssen wir auch nur die Anforderungen an eine Lösung kennen um eine Lösung zu entwickeln. Diese stellen sich für mich wie folgt dar:
Panel: über ALIAS Thermostat
- Über eine Thermostatpage wird ein Setpoint (Solltemperatur) in einem Datenpunkt in 0_userdata.0... gesteuert.
- Ebenfalls gibt es entweder den internen oder den externen Raumsensor, der die aktuelle Raumtemperatur beinhaltet.
Externes Script:
- Eventuell ist ein weiterer Datenpunkt erforderlich, der einen Offset zur Temperatur beinhaltet.
- Wenn Ist-Raumtemperatur +- Offset < Setpoint-Temperatur --> Relay auf 1 (an)
- Wenn Ist-Raumtemperatur +- Offset > Setpoint-Temperatur --> Relay auf 0 (aus)
Das anschalten des Relais kann über einen Steuere-Blockly-Block oder alternativ über setState (JS) erfolgen.
Kann je nach Konfiguration auch POWER1 oder POWER2 sein
oder alternativ über Request mit Backlog und Tasmota Command
Sind die Annahmen hier korrekt?
Ach ja und SetOption114 entkoppelt das Relay von der Hardware-Taste
VG
Genau das habe ich gesucht, ich möchte per Blockly beide Relais steuern, habe jetzt in meinem Script den Baustein genau so verwendet, aber es ändert nichts an den Objekten.
Wie kann ich beide Relais getrennt von einander per Blockly steuern?
-
Finde ich Mega. Weiter so
