NEWS
SONOFF NSPanel mit Lovelace UI
-
@armilar sagte in SONOFF NSPanel mit Lovelace UI:
Moin,
klappt soweit super. Allerdings wird bei mir bei geschlossenem Garagentor das offene Symbol gezeigt und umgedreht.
Das liegt schlicht an meinem Reed-Kontakt, der bei geschlossenem Tor TRUE liefert.Kann ich das im Alias irgendwo invertieren? Oder macht es hier Sinn, noch eine Abfrage für den Status einzubauen, was das TRUE letztendlich bedeutet?
-
<PageItem>{ id: "alias.0.Kontaktsensoren.Garage", offColor: MSGreen, onColor: MSRed, name: "Garagentor", icon: "garage-open", icon2: "garage" }
Da du ja die cardGrid verwendest und den Text opened/closed nicht benötigst, könntest du jetzt einfach die Icons (icon/icon2) ebenfalls drehen (siehe PageItem --> einfachste Variante)
Alternativ kannst du auf den ACTUAL im Alias reagieren und den "val" über eine Funktion im Alias invertieren.
!val
Oder über einen zusätzlichen Datenpunkt gehen, der die Invertierung macht
-
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