Spielzeug :)

[udo1toni]

Genau.
Wenn Du massig Änderungen bekommst, ist es sinnvoller, einfach nur zeitlich gesteuert zu senden, so wie Du es ja auch umgesetzt hast.

Aber um auf Deine ursprüngliche Rule zurück zu kommen: Es gibt ein paar Probleme dabei.
Zum ersten erzeugst Du ja einen Timer, der die Ausführung des beinhalteten Codes um 60 Sekunden verzögert. Das ist schon mal nicht das, was Du willst
Dann nutzt Du newState, was eine implizite Variable ist, die lediglich zur Verfügung steht, wenn eine Rule mit changed oder revceived update getrigert wurde (der Code des Timers kann evtl. den Status der Variable erben, darauf verlassen würde ich mich aber nicht)
Dann prüfst Du auf === null, sorgst aber zu keinem Zeitpunkt dafür, dass die Variable tatsächlich wieder geleert wird.
Und ganz wichtig: Du nutzt eine Variable für den Timer, initialisierst sie aber nicht als Timer Variable. Das mag funktionieren, ist aber auch eher keine gute Idee. Der saubere Ansatz hätte so ausgesehen:

Code: Alles auswählen

// globale Variablen zu Beginn der Datei definieren
var Timer tSend = null

rule "Aktive AC Power"
when
    Item GenericMQTTThingVictronGridACPower changed // Wert geändert
then
    if(tSend !== null)                               // Timervariable gesetzt?
        return;                                      // dann Abbruch

    val strPower = newState.toString                 // hole den Wert als String

    // json Objekt bauen
    val json='{"pos" : 2,"text" : "' + strPower + ' W","icon" : 2708,"duration" : 10,"rainbow": true,"color" : "#FFFFFF"}'

    Anzeigeuhr.sendCommand(json)                     // json senden

    tSend = createTimer(now.plusSeconds(20), [|      // Zeitsperre aktivieren
        tSend = null                                 // Timervariable löschen
    ])
end

Diese Rule triggert nun bei jeder Wertänderung, wird aber sofort beendet, falls die Timervariable gesetzt ist.
Ist die Variable nicht gesetzt, wird der aktuelle Wert ermittelt, ins json integriert und an die Anzeige geschickt. Anschließend wird der Timer gestartet, womit die nächste Ausführung verhindert (abgebrochen) wird.

Läuft der Timer ab, so wird lediglich die Timervariable auf null gesetzt, womit die Sperre wieder aufgehoben ist.

[Thommy2012]

Hallo Udo danke für deine Inspiration.

Werde es gleich mal testen

[Mario084]

Hallo zusammen,

ich habe mir jetzt auch so eine Ulanzi organisiert und gleich mit der Awtrix Light geflashed.

Allerdings habe ich noch Probleme im Verständnis mit der Anbindung an Openhab.

AwTrixSchreibtischCar.sendCommand(json) -> Was ist das für ein Thing? Wie ist es definiert?

Könnte mir da jemand (Udo) weiterhelfen damit ich mal per Openhab einen Befehl senden kann?
Über Postman habe ich 1-2 Befehle erfolgreich senden können...

Danke schon mal! LG

[udo1toni]

Ja, sicher Das AwTrix light Thing sieht bei mir so aus (nur die wesentlichen Channel):

Code: Alles auswählen

     Thing topic awtrix01 "AwTrix Schreibtisch" @ "mqtt" {
          Type string  : car        "Custom car"    [ commandTopic="awtrix/custom/car",retained="true" ]
          Type string  : stats      "Stats"         [   stateTopic="awtrix/stats" ]
          Type switch  : power      "Anzeige"       [ commandTopic="awtrix/power",on="true",off="false",formatBeforePublish="{'power':%2s}"]
     }

Über stats lasse ich einen heartbeat laufen (ein Item wird über eine Rule ON, wenn es ein Update des Topics gibt, ein Timer setzt das Item auf OFF, wenn 20 Sekunden kein Update erfolgt). Darüber bekomme ich also mit, wenn die Uhr abschmiert.
power verwende ich, um die Anzeige zeitgesteuert abzuschalten.
car ist das Topic für die Custom App (wobei es ja in Wirklichkeit nicht so sehr eine App ist, sondern eher eine statische Anzeige, die zyklisch mit eingeblendet wird, aber es ist halt das Wording von AwTrix light)

retained = true bewirkt, dass bei einem Neustart der Ulanzi die Custom App direkt wieder geladen wird, nicht erst, wenn die Rule beim nächsten Mal das Topic beschreibt.

[waywit]

Hallo zusammen

ich habe mir auch so ein "Spielzeug" zugelegt und spiele gerade damit herum... bisher habe ich keinen MQTT und NodeRed Server gehabt, allerdings einen Openhab Server der über diverse Bindings die Daten aus meinem Smart Home (Shellys, ein Zigbee Netzwerk über einen Conbee II und FritzDECT Smart Home Geräte) in einer InfluxDB 2 persistiert und dann per Grafana visualisiert...
Ich habe zwar mit MQTT herumgespielt würde aber gern drumherum kommen und direkt aus OpenHab die http/API nutzen um definierte Werte auf der AWTRIX Uhr anzuzeigen. Da meine Erfahrung in Openhab bisher eher auf der Nutzung bereits vorhandener Bindings beruht, fehlt mir aktuell das Know How wie ein entsprechenden Empfänger (AWTRIX API) in OpenHab anlege und wie ich definierte Werte Ann an diese senden kann. Hat hier jemand eine Empfehlung für eine Lesequelle oder ein paar direkte Tips wie ich so etwas in Openhab mit AWTRIX implementieren kann? Erstes Projekt wäre ein Shelly Plus 1PM an meinem Balkonkraftwerk, der dann den aktuellen Ertrag auf der AWTRIX anzeigen soll (aber auch in der InfluxDB speichert).

Vielen Dank
Jens

[udo1toni]

Warum willst Du auf mqtt verzichten? Auf einem Raspberry (oder auch jeder anderen Plattform, auf der openHAB läuft) lässt sich z.B. Mosquitto mit einfachsten Mitteln zusätzlich installieren.
mqtt ist wesentlich komfortabler zu verwenden als die jeweilige http API.
Außerdem gibt es jede Menge heißen Scheiß mit mqtt der über http eine echte Frickelei ist (ich habe z.B. meinen ID. 3 über weconnect2mqtt so eingebunden, da das weconnect Binding leider hoffnungslos hinterher hinkt und auch nicht absehbar ist, dass sic hdaran etwas ändern wird)

[waywit]

Erstmal vielen Dank für deine schnelle Antwort… Ich wollte vermeiden ein weiteres System hochzuziehen und zu maintained nur um 2-3 Werte auf der Uhr anzuzeigen, die ich ja bereits über OpenHAB gesammelt und in der Influx gespeichert habe. Die Werte kommen aus einem Shelly Plus 1PM… klar könnte ich dort MQTT aktivieren und dann per Node Red zur Uhr bringen… ich dachte das es einfacher wäre mir z.B. ein Skript in OpenHAB zu bauen, das z.B. alle 30 Sekunden einen neun aktuellen Wert an Awtrix schickt, der dann so lange dort angezeigt wird bis der nächste Wert kommt
Ist das sehr kompliziert in OH umzusetzen?

[udo1toni]

Grundsätzlich zeigt die Ulanzi (mit der AwTrix-Light Firmware) das an, was Du hinsendest, bis Du etwas anderes hinsendest (auf Wunsch zyklisch wechselnd mit anderen Anzeigen). Wenn Du Text sendest, der nicht auf das Display passt, wird die Anzeige gescrollt, das genaue Verhalten ist dabei in Teilen konfigurierbar. Man muss also anzuzeigende Informationen nur einmal senden, die Uhr zeigt sie so lange an, bis man die Informationen durch andere ersetzt (oder sie gar komplett löscht).
Natürlich kannst Du aus einer Rule heraus auch einfach den passenden Aufruf per http Zugriff senden.
Mqtt Definition in openHAB3:

Code: Alles auswählen

UID: mqtt:broker:mymqtt
label: Mosquitto
thingTypeUID: mqtt:broker
configuration:
  host: 192.168.178.55

UID: mqtt:topic:mymqtt:awtrix01
label: AwTrix Schreibtisch
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mymqtt
location: mqtt
channels:
  - id: car
    channelTypeUID: mqtt:string
    label: Custom car
    description: null
    configuration:
      commandTopic: awtrix/custom/car
      retained: true
      postCommand: false
      formatBeforePublish: "%s"

Das obere ist die mqtt Bridge (also die Verbindung zum Broker). Man kann da massig Parameter setzen, es läuft aber sobald man die IP hinterlegt (unter der Voraussetzung, dass Mosquitto den Standard Port verwendet)
Das untere ist alles, was man definieren muss, damit man bequem mit einem Befehl eine App zu AwTrix Light senden kann. Im Grunde gibt man das Topic an. Hier heißt die App "car" - da sie retained ist, wird sie unmittelbar von der Ulanzi angezeigt, selbst wenn diese neu gestartet wird - der Broker kümmert sich darum, openHAB muss sich buchstäblich um nichts kümmern, außer die App einmalig zu schicken bzw. zu aktualisieren)

Mit http:

Code: Alles auswählen

UID: http:url:awtrix02
label: AwTrix Light
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: http://192.168.178.65/api
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: POST
  contentType: application/json
  timeout: 3000
  bufferSize: 2048
channels:
  - id: car
    channelTypeUID: http:string
    label: Car App
    description: null
    configuration:
      mode: WRITEONLY
      commandExtension: custom?name=car2
      escapedUrl: false

http braucht natürlich nur ein Thing.
In beiden Fällen muss die Rule anschließend lediglich ein JSON Objekt bauen und dies an das verlinkte String Item senden.

Code: Alles auswählen

rule "Car battery SOC"
when
    Item VWChargeSOC changed
then
    var strColor = "#00FF00"
    val strSOC = VWChargeSOC.state.toString
    var json='{"pos" : 2,"text" : "' + strSOC + ' %","icon" : 5717,"duration" : 9,"color" : "' + strColor + '"}'
    AwTrixSchreibtischCar.sendCommand(json)
end

Tatsächlich hab ich mir viel zu viele Gedanken gemacht, wenn man den http Teil als Thing/Channel kapselt, ist es halb so wild.

Was allerdings bleibt: Wenn die Ulanzi neu startet, erscheint die Nachricht erst, wenn die Rule einen neuen Wert sendet, per mqtt wird (auf Wunsch - retain) der letzte Zustand unmittelbar an die Ulanzi übertragen (das ist mit http nicht möglich - mindestens müsste man eine aktive Überwachung des Status einbauen, die dann, falls die App nicht gelistet ist, ein Update der Anzeige erzwingt.
Man kann den Channel auch weg lassen und direkt per Action Daten schreiben (geht sowohl mit http als auch mit mqtt), aber warum sollte man das tun, der Code wird nur komplexer.

[waywit]

Hallo, super vielen Dank für deine ausführliche Antwort… und vielmals um Entschuldigung für meine späte Antwort, ich war leider die letzte Zeit unterwegs und bin bisher nicht dazu gekommen hier weiterzumachen Jetzt liegt es bei mir etwas mit deinen Infos etwas anzufangen.
Nur noch ein paar kurze Fragen für das Verständnis eine „Newbies“ bei OpenHAB… ich nutze dann das http Binding und erstelle ein entsprechendes Thing an deinem Vorschlag angelehnt für meine Uhr… dann noch die Regel die, hier ist mir nicht 100% klar wo ich diese in OpenHAB eigentlich anlege..? Gibt es da eine gute Lektüre bzw. Tipp wo ich mich mal einlesen könnte?

Vielen lieben Dank nochmal für deine Hilfe

[udo1toni]

Genau. Du brauchst eine Verbindung zur Anzeige, das erledigst Du per http Binding - wobei ich mqtt immer noch bevorzuge
Du legst ein Thing für die Anzeige an und dann halt die benötigten Channel.
Mein Tipp an dieser Stelle wäre, einen Channel pro AwTrix light App zu definieren. Dabei handelt es sich ja in Wirklichkeit um eine reine Anzeigefunktion, d.h. wenn Du eine AwTrix light App definierst, dann legst Du lediglich fest, was auf der Anzeige für einen festgelegten Zeitraum - zyklisch mit allen anderen Apps - angezeigt werden soll.

Die Rule wird dann verwendet, um die eigentlichen Informationen über den definierten Channel an die Ulanzi mit AwTrix light zu schicken.

Es gibt ein Buch von Marianne Spiller zu openHAB2. Leider kann man das guten Gewissens nicht mehr empfehlen, auch wenn die Strukturen sich nicht grundlegend geändert haben - zu groß sind die Unterschiede zwischen openHAB2 und openHAB3, und damit tut man einem Neuling halt keinen Gefallen.

Die beste Option ist und bleibt die offizielle Dokumentation.
Insbesondere die Abschnitte Welcome to openHAB und Concepts sind sehr wichtig für das Verständnis von openHAB.

Was die Konfiguration betrifft, so gibt es grundsätzlich mal zwei Wege, nämlich die Konfiguration per UI und die Konfiguration per Textdateien.
Als Neueinsteiger wirst Du ziemlich sicher die UI bevorzugen, ich bin allerdings schon seit openHAB1.0 mit dabei. Damals gab es nur eine Art der Konfiguration, es gab schlicht keine UI (zur Administration), sondern lediglich die UI für die Steuerung der Geräte (der Standard hieß Classic UI - heute gibt es noch die Basic UI mit weitgehend identischer Funktionalität - ich habe damals GreenT verwendet, schade, dass es die nicht mehr gibt)

Wenn Du in der Administrationsebene der Main UI bist, gibt es dort den Punkt Rules, dort kannst Du Rules über die UI anlegen. Dabei gibt es verschiedene Optionen, von ganz einfachen Dingen - Wenn dies dann das, außer jenes - bis hin zu Scripten, die dann letztlich als "dann das" eingebunden werden, also - Wenn dies dann führe das Script aus außer jenes .
Die Scripte wiederum können in verschiedener Form erstellt werden - welche Sprachen dabei unterstützt werden ist erweiterbar, da kommt es vor allem auf die Community an - für Einsteiger ist sicherlich Blockly empfehlenswert, ich kann dem Kästchenschubsen aber nichts abgewinnen und schreibe meine Scripte in der Rules DSL (Domain Specific Language), die ist optimiert für die gewünschte Anwendung in openHAB.

Ich notiere Rules grundsätzlich als Textkonfiguration, daran erkennbar, dass so eine Rule einen Rahmen hat:

Code: Alles auswählen

rule "Name der Rule"
when
    // hier werden die Trigger notiert
then
    // hier steht das eigentliche Script
end

Der Teil zwischen when und then ist in den UI Rules der Wenn-Teil, der Part zwischen then und end ist in der UI-Rule der Dann-Teil. Einen Außer-Teil gibt es bei der Textform nicht, wenn es Randbedingungen gibt, in denen die Rule nicht greifen soll, dann muss man das im Script berücksichtigen.
Du kannst also solche Rules grundsätzlich auch über die UI eingeben, musst dann aber den Rahmen weg lassen bzw. die Trigger getrennt in der UI eingeben und darauf achten, nur den Teil zwischen then und end als Script einzufügen, sonst gibt es Fehlermeldungen.

Die Textrules legt man über eine oder mehrere Dateien an, und zwar im Verzeichnis $OPENHAB_CONF/rules/ wobei die Textdatei die Endung .rules aufweisen muss. Auf einem Raspberry Pi mit Standardinstallation verweist $OPENHAB_CONF auf /etc/openhab/, also ergibt sich z.B. ein Dateiname /etc/openhab/rules/meine.rules für eine Datei, in der gewöhnliche DSL Rules angelegt werden.