Schickt falsche Befehle über MQTT

[udo1toni]

Nein, das geht nicht.

Ich hab ja bereits erwähnt, und ich tue es gerne nochmal, die Nightly ist erst dann wieder sinnvoll, wenn es dafür auch eine offizielle Information gibt, dass die Probleme mit der Umstellung behoben sind.

Schau in PaperUI nach, was dort für Konfigurationsmöglichkeiten vorgesehen sind. Mehr geht über die Textkonfiguration auch nicht.
Welche Parameter wie zu konfigurieren sind, kann man mit etwas Mühe über die REST API aus dem JSON herauslesen. Dazu muss man sie aber erst mal mit Paper UI anlegen.
Frag notfalls im englischen Forum nach (oder auch in github) ob der Fehler noch besteht.

Der einfache Workaround führt über Proxy Items und die mqtt Action innerhalb einer Rule, dort kannst Du senden, was Du willst und das Addon wird den Payload nicht manipulieren, das funktioniert für andere hier auch schon.

[D3ltorohd]

Der einfache Workaround führt über Proxy Items und die mqtt Action innerhalb einer Rule, dort kannst Du senden, was Du willst und das Addon wird den Payload nicht manipulieren, das funktioniert für andere hier auch schon.

Könntest du mir an meiner Situation ein konkretes Beispiel geben, hab davon leider wenig Ahnung. Bin froh das ich das damals so hinbekommen habe. Wenn ich für einen Rollo ein Beispiel hätte, würde ich den Rest denke ich selber hinbekommen.

Ich wollte nur mal rein schauen in die Nightly, hab davor die Platte mit Clonezilla geclont. Mittlerweile wieder auf stable 2.4 zurück gespielt, quasi image zurück.

Sollte das den so wie ich das habe, beim nächsten Stable Update auch funktionieren, oder sendet er beim Rollershutter immer nur 0 stop und 100 ?

[udo1toni]

Ein Rollershutter Item kennt die Status 0 bis 100 (plus UNDEF und NULL) sowie die Kommandos UP, DOWN, STOP und die Zahlen 0 bis 100.
Entsprechend muss ein Rollershutter Channel genau diese Kommandos und Status empfangen bzw. senden.

Das MQTT2 Binding hat da einen Bug, der die korrekte Weitergabe des Steuerbefehls verhindert. Natürlich wird dieser Bug beseitigt, sobald wieder Normalität einkehrt. (Der Entwickler des Bindings ist sehr aktiv und auch sehr darum bemüht, openHAB voranzubringen. Entsprechend ist er auch motiviert, solche Fehler auszumerzen.)

Das Vorgehen für einen Rollershutter mit Proxy sähe so aus:
Items:

Code: Alles auswählen

Rollershutter myRollershutter "Mein Rollladen [%d %%]"
Number mqttReceive {channel="<der Channel, über den der Status als Zahl gemeldet wird>"}

Rules:

Code: Alles auswählen

rule "receive shutter"
when
    Item mqttReceive received update
then
    if(mqttReceive.state instanceof Number)
        myRollershutter.postUpdate((mqttReceive.state as Number))
end

rule "send shutter"
when
    Item myRollershutter received command
then
    val mqttActions = getActions("mqtt","mqtt:bridge:myBroker")
    switch(receivedCommand) {
        case UP: mqttActions.publishMQTT("mytopic","up")
        case DOWN: mqttActions.publishMQTT("mytopic","down")
        case STOP: mqttActions.publishMQTT("mytopic","stop")
        default: mqttActions.publishMQTT("mytopic",receivedCommand)
    }
end

Wobei natürlich der korrekte Broker eingetragen sein muss, ebenso wie das korrekte Topic und der korrekte Wert, der zu senden ist.
Default ist dabei die Zeile, die ausgeführt wird, wenn kein anderer Wert ausgeführt wird, in diesem Fall also alle Zahlen. receivedCommand kann nur die aufgeführten Werte enthalten, nicht jedoch NULL oder UNDEF, denn dies sind keine gültigen Befehle.

[D3ltorohd]

Vielen Dank @udo1toni mal sehen ob ich das hin bekomme.

Mein Thing bleibt so ? Oder hat das erst mal keine Funktion ?

[udo1toni]

Da openHAB aus der Rule heraus per Action sendet, spielt das Thing hier nur für den Empfang eine Rolle.

[D3ltorohd]

Guten Abend, @udo1toni

ich will jetzt noch mal genauer nachhacken, ich poste dir hier mal wie ich das momentan gelöst habe, da das ja aktuell nicht geht mit dem Build hast du ja eine andere Variante geschrieben, nur leider schaue ich da nicht so ganz durch. Ich poste jetzt mal das ganze für einen Rollo, wenn du Lust und Zeit hast, könntest du mir vllt an dem Beispiel eine rule fertig machen, das sie mit meinen Rollos funktioniert ?

Thing ::

Code: Alles auswählen

Thing topic wzlinks "Wohnzimmer li"  @ "Wohnzimmer" {
    Channels:
        Type rollershutter : WZ_Jalousie_links     "Wohnzimmer li"      [stateTopic="/JaroFB/LastAction_Channel_01", commandTopic="/JaroFB/set", UP="up 1", DOWN="down 1", STOP="stop 1"]
}

Item ::

Code: Alles auswählen

Rollershutter       WZ_Jalousie_links        "Wohnzimmer li [%d %%]"            <blinds>    (Jalousien, WZ_Jalousien)           {channel="mqtt:topic:embedded-mqtt-broker:wzlinks:WZ_Jalousie_links"}

und die Sitemap zum steuern von Hand ::

Code: Alles auswählen

      Frame label="Jalousien" {
				Default item=WZ_Jalousie_links label="Jalousie links"

			}

So da das mqtt binding nicht richtig funktioniert und meine Befehle so nicht sendet, hast du mir hier ja eine alternative über Rules geschrieben, könntest du mir diese mal speziell auf diesen Rollo anpassen ? Das das ganze weiterhin mit dem Astro Binding und zufällig läuft.

MQTT an der Gegenstelle sollte sowas empfangen ::

Code: Alles auswählen

/JaroFB/set up 1

Zufällig läuft das ja alles über eine Rule die ich dir ja schon geschickt hatte und du mir ein anderes Beispiel geschickt hast.

[udo1toni]

Es läuft darauf hinaus, die mqtt action zu nutzen:

Code: Alles auswählen

rule "send mqtt action"
when
    Item myRollershutterControlItem received command
then
    val mqttActions = getActions("mqtt","mqtt:systemBroker:embedded-mqtt-broker")
    switch (receivedCommand) {
        case UP: {
            mqttActions.publishMQTT("/JaroFB/set","up 1")
        }
        case DOWN: {
            mqttActions.publishMQTT("/JaroFB/set","down 1")
        }
        case STOP: {
            mqttActions.publishMQTT("/JaroFB/set","stop 1")
        }
        default: {
            mqttActions.publishMQTT("/JaroFB/set","level "+receivedCommand.toString)
        }
    }
end

Die letzte Option wäre der Befehl, um den Laden auf eine bestimmte Position zu fahren. Falls das so nicht geht, kannst Du den default-Part auch weg lassen. Ob die Rule wirklich funktioniert, kann ich allerdings gerade nicht prüfen. Da auslösende Item myRollershutterControlItem ist nur dazu gedacht, das Kommando entgegen zu nehmen, es kann also z.B. in der Sitemap als Rollershutter Item verwendet werden, aber es ist ungebunden, weder Channne noch ein Binding sind mit ihm verknüpft.
Für Deine Rule (bzw. meine optimierte Version) ergibt sich allerdings ein Problem, nämlich, das Topic korrekt zu bestimmen. das kann man aber mit einer Hashtable oder einem Array lösen.

[D3ltorohd]

Oh je oh je, ich glaub ich gib's auf. Es sind ja 14 Rollos, die ich ansteuern möchte. Wo wird das den definiert, weil er ja dann auch andere Channel Nr schicken muss. Vllt habe ich noch ein wenig Geduld, denke die 2.5 M2 steht kurz vor RLS

[udo1toni]

Was sind das denn für Geräte? Vielleicht wäre eine andere Firmware verfügbar, die besser mit openHAB harmoniert.

[D3ltorohd]

Naja, das sind Rollos von Jarolift. Selber bieten die nur einen Timer an, total nutzlos.

Ich habe einen nanoCUL, mit Signalduino drauf, was es leider nur für FHEM gibt, dort gibt es ein weiteres Modul, welches mit meinen Rollos kommunizieren kann. In FHEM habe ich MQTT Bridges angelegt und die horchen eben auf den Befehl, den ich brauche. Ich denke da kann man nicht viel anders machen.