openhabforum.de

Moin Zusammen,
moin Udo1Toni,

ein gesundes neues Jahr wünsche ich noch in die Runde.

Leider funktioniert det Tip mit dem Group Topic an die Tasmota-Geräte nicht.
Da ich sowohl Power als auch Dimmer in einer Rule ansprechen will habe ich es wie folgt gelöst...

Code: Alles auswählen

rule "Tasmota-Status"
    when
        //Time cron "*/30 * * * * ?" or
        Time cron "0 0 0 * * ?" or
        Item SystemStart_15Min changed to ON       //schalter 15Min nach Systemstart auf ON
    then
        //get stats of tasmota devices"
        val mqttActions01 = getActions("mqtt","mqtt:broker:RzHomeControl_MQTT_Broker")
        mqttActions01.publishMQTT("cmnd/tasmotas/POWER",null, false)
        val mqttActions02 = getActions("mqtt","mqtt:broker:RzHomeControl_MQTT_Broker")
        mqttActions02.publishMQTT("cmnd/tasmotas/FanSpeed",null, false)
        val mqttActions03 = getActions("mqtt","mqtt:broker:RzHomeControl_MQTT_Broker")
        mqttActions03.publishMQTT("cmnd/tasmotas/Dimmer",null, false)
end

Laut der Erleuterungen zum MQTT Binding müsste es wie folgt aussehen:

Code: Alles auswählen

        val mqttActions01 = getActions("mqtt","mqtt:broker:RzHomeControl_MQTT_Broker")
        val mqttActions = getActions("mqtt","mqtt:broker:myBroker")

Code: Alles auswählen

        mqttActions01.publishMQTT("cmnd/tasmotas/POWER",null, false)
        mqttActions.publishMQTT("mytopic","myvalue", true)

Wenn ich es nur mit Power teste und die 01 weg lasse ging es auch nicht

Ist da noch ein Fehler drin?

udo1toni hat geschrieben: ↑30. Dez 2023 20:49 immer vorausgesetzt, das Tasmota Device ist auch korrekt konfiguriert

???Was heißt das genau?

Vielleicht wird die Rule auch zu früh ausgeführt, es dauert immer noch sehr lange bis das MQTT Binding läuft und alle Geräte da sind.
Kann die Rule natürlich auch auslösen wenn ich von einem der Tasmota-Geräte eine Temperatur gemeldet bekomme...

Von Visual Studio bekomme ich auch eine Fehlermeldung (Siehe Bild im Anhang)
Muss das NULL evtl. in Anführungsstriche?

Code: Alles auswählen

"cmnd/tasmotas/POWER","null", false

Danke und Gruß
Florian

Nein, das null darf nicht in Anführungszeichen stehen, es geht nicht darum, einen String "null" zu senden, sondern eine leere (eben null) Payload.
Auch ein "" ist übrigens etwas anderes als null...
Du musst die action nicht mehrfach anlegen, Du kannst einfach die erste Action nutzen.
Ich muss das aber mal bei mir durchspielen, aber erst morgen...

…ich Dussel

Die action ist ja auch immer die selbe

Also, der Befehl an sich funktioniert, nur beschwert sich openHAB wegen des uneindeutigen Call (Ambiguous feature call).
Keine Ahnung, ob man das weg bekommt, das ist aber "nur" eine Warnung im Editor, die nicht geloggt wird.

Moin Zusammen,

die Schaltzustände der Tasmota-Geräte werden jetzt korrekt übertragen.
Die Rule löst jetzt aus wenn ich vom "letzten" Gerät das Datum des Messbeginns übertragen bekommen habe.
Ich gehe davon aus, dass dann alle MQTT-Verbindungen zu den Tasmotageräten stehen.

Nur die Geräte die so programmiert sind, dass der Schaltzustand immer ON ist (weder über MQTT oder Tasmota UI schaltbar) antworten nicht.
Ist aber unproblematisch da diese Schaltzustände für mich nicht relvant sind.

Wieder ein Problem weniger

Aber mein openHAB benötigt für den Reboot immer noch ewig und das MQTT-Binding wird immer als letztes initialisiert.
Dauert ca. 15-20 Minuten

Außerdem bekomme ich pausenlos diese Meldung in der openhab.log:

Code: Alles auswählen

2024-01-04 12:54:48.061 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'synology-1' failed: cannot invoke method public abstract org.openhab.core.types.State org.openhab.core.items.Item.getState() on null in synology
2024-01-04 12:55:48.008 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'synology-1' failed: cannot invoke method public abstract org.openhab.core.types.State org.openhab.core.items.Item.getState() on null in synology
2024-01-04 12:56:48.085 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'synology-1' failed: cannot invoke method public abstract org.openhab.core.types.State org.openhab.core.items.Item.getState() on null in synology
2024-01-04 12:57:48.035 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'synology-1' failed: cannot invoke method public abstract org.openhab.core.types.State org.openhab.core.items.Item.getState() on null in synology

Ich kann damit aber nichts anfangen...
Bekomme sonst immer konkrete Zeilenangaben. Was bedeutet "Script execution of rule with UID 'synology-1' "?
Ist damit der erste If-Satz gemeint oder die erste Rule in der synology.rules (siehe Anhang)?

Danke und Gruß
Florian

Ja, das ist direkt erklärbar.
Du verwendest das Objekt triggeringItem.
Das Problem: triggeringItem steht seit openHAB3 nur als Objekt zur Verfügung, wenn die Rule mit Member of <GroupItem> getriggert wurde. Das ist nicht schön, aber so ist es halt...

Einfachste Lösung: Du stellst den Trigger entsprechend um:

Group gSynologyBigger anlegen und die Items
- Synology_RAID_RaidUsedPercent
- Synology_CPU_MemRealUsedPercent
- Synology_System_Temperature
- Synology_Disk_Temperature1
- Synology_Disk_Temperature2
dieser Gruppe zuordnen.
Den Triggerblock der ersten Rule mit Member of gSynologyBigger changed ersetzen.
Group gSynologyUnequal anlegen und die Items
- Synology_System_SystemStatus
- Synology_System_PowerStatus
- Synology_System_SystemFanStatus
- Synology_System_CpuFanStatus
- Synology_Disk_Status1
- Synology_Disk_Status2
- Synology_RAID_RaidStatus
- Synology_System_UpgradeAvailable
dieser Gruppe zuordnen
Den Triggerblock der zweiten Rule mit Member of gSynologyUnequal changed ersetzen.

Mutmaßlich lassen sich die Rules ob der verwendeten Typen stark vereinfachen (kommt dabei natürlich auch auf die Definition der Items an).

Die Fehlermeldung bezieht sich tatsächlich auf die erste Rule in der Datei. Da Rules in Textdateien keine definierte UID haben, wird der Dateiname und die fortlaufende Nummer als UID verwendet.

Moin Zusammen,

danke udo1toni, dass mit dem triggeringItem hat funktioniert.
NAchdem ich eigentlich nur noch die Fehler wegen Java und der falschen Version einiger Addons (3.1.0 auf 3.4.4) habe ich meinen neuen Raspberry Pi 5 mit 8 GB genommen und Raspberry OS 64 bit installiert. Dann OH 4.1.0 stable installiert (Openhabian unterstützt den RPi5 noch nicht).
Alle Bindings installiert und nach und nach die Things aktiviert.

Nun benötigt mein OH ca. 2 Minuten biss es vollständig läuft.
Keine ERROR-Meldungen und die openhab.log ist sogar noch nach einem Tag recht klein

Danke für Eure Unterstützung
Gruß
Florian

Ein Problem habe ich noch...
Spreche es hier an weil wir hier den Ansatz begonnen haben.

Die Schalter der Tasmota-Komponenten bleiben auich in OH4 alle auf NULL.
Trotz:

Code: Alles auswählen

val mqttActions = getActions("mqtt","mqtt:broker:RzHomeControl_MQTT_Broker")
mqttActions.publishMQTT("cmnd/tasmotas/POWER",null, false)
mqttActions.publishMQTT("cmnd/tasmotas/FanSpeed",null, false)
mqttActions.publishMQTT("cmnd/tasmotas/Dimmer",null, false)

Auch Visual Studio beschwert sich weiter...

Code: Alles auswählen

Ambiguous feature call.
The extension methods
	publishMQTT(ThingActions, String, String, Boolean) in MQTTActions and
	publishMQTT(ThingActions, String, byte[], Boolean) in MQTTActions
both match.(org.eclipse.xtext.xbase.validation.IssueCodes.ambiguous_feature_call)

Ich überlege meine alte Konfig wieder zu übernehmen in der ich jedem Item als Channel sowohl die state als auch die result zugeordnet habe...
Das lief zuverlässig...

Code: Alles auswählen

{channel="mqtt:topic:RzHomeControl_MQTT_Broker:Tasmota044:An_Aus_state" , channel="mqtt:topic:RzHomeControl_MQTT_Broker:Tasmota044:An_Aus_result"}

Gibt es noch eine Alternative? Alles zurückbauen ist unbefriedigend

Danke und Gruß
Florian

Du kannst noch versuchen, statt null tatsächlich "" zu senden, evtl. funktioniert das auch und "" wird eindeutig als String erkannt.

Prüfe bitte nach, ob die Geräte alle auf das Group Topic cmnd/tasmotas/ konfiguriert sind, nicht, dass es versionsbedingt bei Dir anders lautet.
Notfalls kannst Du das Group Topic über die Tasmota Konsole (oder per mqtt...) auch passend nach eigenen Wünschen setzen.
Die Funktion als solche ist definitiv gegeben, das habe ich bei mir auch getestet (Dimmer habe ich nicht, ebenso habe ich keine mehrkanaligen Geräte - bzw. die laufen bei mir als Rollershutter, wo mich dann nur die Position interessiert).
Wenn alle Stricke reißen, kannst Du auch jedes Gerät einzeln anfragen. Der Punkt ist aber, diese Anfrage muss nur einmal gesendet werden, wenn openHAB startet. Das erledigt die Rule mit der Anforderung des aktuellen Status (leerer Befehl). Ansonsten sendest Du einen bestimmten Befehl und das führt immer zu einer Antwort auf stat/<topic>/BEFEHL, weshalb dieses Topic auch das einzig sinnvolle für die Auswertung des Status ist.

udo1toni hat geschrieben: ↑8. Jan 2024 08:13 Group Topic cmnd/tasmotas/

Wo/wie setze man den Group Topic?
Ich kann in den >Einstellungen< >MQTT Komfiguratin< ein mal topic setzen und ein mal full topic setzen.
aber wo/wie setze ich group topic?

openhabforum.de

[gelöst] openHAB reboot > 30 Min

Re: openHAB reboot > 30 Min

Re: openHAB reboot > 30 Min

Re: openHAB reboot > 30 Min

Re: openHAB reboot > 30 Min

Re: openHAB reboot > 30 Min

Re: openHAB reboot > 30 Min

Re: [gelöst] openHAB reboot > 30 Min

Re: [gelöst] openHAB reboot > 30 Min

Re: [gelöst] openHAB reboot > 30 Min

Re: [gelöst] openHAB reboot > 30 Min