LoxBerry MQTT

[Federbein0815]

Hallo, hat jemand eine Idee? Ich habe schon einige MQTT HTTP Request erfolgreich in die Loxone eingebunden, nun scheitere ich aber. Über UDP funktioniert es ohne Probleme. Über HTTP bekomm ich in der VIsualisierung nichts angezeigt. Könnte es was mit der folgenden konvertierung des WifiScanners zutun haben?


19:30:07.080 OK: Sending Data 'wifiscanner/JuliaHandy/0' to MQTT broker localhost:1883

19:30:07.081 OK: Sending Data 'wifiscanner/BastiHandy/1' to MQTT broker localhost:1883

Also genaugenommen mit den /

Vielen Dank für Eure Mühe.

LG

[Christian Fenzl]

Servus!
Ich verstehe das Problem nicht ganz - was kommt an und was nicht?

[hiasinator]

Hallo, hab heute Loxberryupdate durchgeführt und W-Lan Passwort geändert. Seit dem erhalte ich die Werte nicht mehr per HTTP in der Loxone!
Hab schon Plugin neu installiert, alles mehrfach neu gestartet und einen Sensor im Loxconfig mal neu erstellt! Bringt alles nichts. Die Werte werden nicht mehr aktualisiert.
In der Incoming overview sind aber alle Werte richtig da! UDP hab ich nicht versucht. Ich will eigentlich auf HTTP bleiben!
Installierte Loxberryversion 2.0.1.3
MQTT Gateway v1.1.1

Irgend eine Idee?

LG
Mathias

[Christian Fenzl]

Schick mir mal das letzte MQTT Gateway Logfile (gerne auch per PM).
Im LoxBerry bei den Miniservern mal den Auth-Check durchführen, ob der noch funktioniert, bzw. den Selbsttest in „Mein LoxBerry“. Ist dort alles OK?
Lg Christian

[hiasinator]

Danke für den Tipp mit dem Selbsttest! Kommunikation zum Miniserver ging nicht, weil ich Pfosten das PW geändert hab
und das nicht richtig ins Loxberry übertragen hab! 😆
Läuft wieder alles wie es soll! DANKE

LG Mathias

[HRA]

Hallo,
also nachdem ich fast den gesamte Thred sowie den vitoconnect durchstöbert habe, komme ich trotzdem nicht weiter.
Ich denke es hat etwas mit meiner Kommunikation MQTT-Plug-In zum MS zu tun, da caldav-daten auch nicht funktionieren.
Anbei die scrennshots und das mqtt-log.
Folgende Szenarie
- 2 MS Gen1 (Gateyway+client)
- beide MS im loxberry bekannt und Konnektivitätsprüfung erfolgreich
- virtuelle Eingänge und die Programmlogiken sind im MS2 (client) ausgeführt
- MQTT ist der MS01(gateway) angegeben
- in der Subscription ist der Verweis auf MS2 angelegt "|2"
- 2 MQTT-features vorhanden -> caldv4lox und vitoconnect
- die virtuellen Eingänge sind entsprechend der MQTT-Einträge benannt (kopiert)
- bei beiden bekomme ich keine In-Daten im MS
- Daten im MQTT-Incomming sind richtig und auch aktuell zu den devices
- Virtuelle Ausgangsbefehle funktionieren, "reconnect" beim mqtt läuft und die vitoconnect Warmwasssr-Soll-vergabe wird auch in der Heizung übernommen

ich komme einfach bei der Fehlersuche nicht weiter, hat jemand einen Tip wo ich etwas falsch machen könnte.
hier das log-fill [ATTACH]n254018[/ATTACH]

[HRA]

Hier noch die restlichen screenshots

[Christian Fenzl]

Kannst du das MQTT Gateway Log noch anhängen - das ist irgendwie nicht mitgekommen.

Von den Screenshots scheint alles zu passen.

EDIT: Log ist eh da, hat er am Handy nicht angezeigt!

[HRA]

auch im log sehe ich keine fehler.
Aber im MS kommt nichts an, habe sicherlich irgendwo eine "einfache" Grundeinstellung falsch, aber kann sie eben nicht finden
Danke schon mal für deine Hilfe
Für heute muss ich Schluss machen, schaue morgen wieder hier rein :-)

[Christian Fenzl]

Kannst du mal Restart im Plugin machen, und mir das neu erstellte Log schicken. Beim Start wird die Config gelesen, das würde ich gerne anschauen.

Was du auch noch probieren könntest:
- In der Incoming Overview, mit der Advanced Table information, für .../dhw/value das Caching deaktivieren - kommt dann was durch?
- Gibt es bestimmt keinen anderen Input am MS1 oder MS2, der vitoconnect_heating_solar_sensors_temperature_dhw_ value heißt?
- Miniserver neustarten. Bei UDP hat das in letzter Zeit öfter mal geholfen, und "ein neuer Boot tut immer gut"

Sonst könnt ich dir eine spezielle DEBUG-Version schicken, die im Log mehr ausgibt, speziell bezüglich an welchen MS die Übermittlung geht.

Danke und lg,
Christian

[HRA]

logfile ist per PN raus
im Mosquito-Log habe ich die selbe Anzeige wie TICO im Post 563
Rest deiner Angaben probiere ich noch aus

[Tico]

I am having similar problems with MQTT v1.1.1. The MQTT flow to the Miniserver 1 is working fine, but Miniserver 2 MQTT flow doesn't work.

I have just done a clean install of Loxberry 2.0.1.3 (no upgrade from 1.4). I have a installed a few plugins on the new image including MQTT v1.1.1. I am endeavoring to better balance the loads on the Miniserver by transferring some logic from Miniserver 1 (Gateway) to the Miniserver GO (Client - Miniserver 2).

I have confirmed "Check Miniserver authentication" for both Miniservers (all ok).

1. MQTT install log shows no indication of any problems.

2. I have four subscriptions -

apc/#|1,2
fronius/#
miele/#
robonect/#

3. MQTT Gateway log shows the following message for topics apc, fronius, miele -

09:14:03.537 WARNING: Incoming topic does not match any subscribed topic. This might be a bug

09:14:03.537 WARNING: Topic: apc

robonect has no error message.


4. The Mosquitto log has the following error -



5. I rolled back to MQTT v1.1 to see if it made a difference. No success there.

6. I changed the SD Card on the Client also. No success there.

I have run out of ideas to try...

[Tico]

Thanks Christian. And the Mosquitto log software error? Is that related?

[Christian Fenzl]

The mosquitto log error is not related.
It is some kind of a design issue of LoxBerry permissions for reading system / daemon logs via the WebIf.
I already tried to fix this in the plugin, but it needs to be addressed directly in LoxBerry-Core.

[Christian Fenzl]

That’s your issue: https://github.com/christianTF/LoxBe...eway/issues/47

[Christian Fenzl]

Tico
Appending to my comment #563.3, could you try this workaround:

Instead of subscribing
apc/#|1,2
try to subscribe
apc|1,2

Same with fronius and miele, as both also directly send json data in their main topic.

[Tico]

Removing /# from the subscriptions has fixed the problem. Thanks for the workaround!

[Christian Fenzl]

The "This might be a bug" message was very predictive ;-)

[Christian Fenzl]

HRA Danke für das Log.
In deiner Config steht laut Logfile das Senden an einen anderen MS bei den zwei Subscriptions nicht drin (toMS ist in der Config leer).

{
'id' => 'caldav4lox/events/#',
'toMS' => []
},
{
'toMS' => [],
'id' => 'vitoconnect/#'
}

Kannst du nochmal einen Refresh auf der Subscription-Seite machen, und schauen, ob du eventuell einen JavaScript-Fehler im Browser bekommst, wenn du speicherst?

[Christian Fenzl]

Also:
- Subscriptions öffnen - Sind die Pipes da?
- Eintragen und speichern
- F5 zum Browser aktualisieren - Sind die Pipes da?

Wenn die Einträge verschwinden, funktioniert das Speichern nicht. Im LoxBerry Healthcheck alles ok?

[HRA]

Christian Fenzl
habe im subscript derzeit ohne "|2" drinstehen, d.h. er müsste auf Master-MS01 senden
Habe dort 4 VI (1x caldav, 3x vitoconnect) angelegt und diese im MS2 (client) gelöscht.
Neustart des MS (harter Spannungsreset) durchgeführt
restart des subscript und retransmit angestoßen -> keine Fehlermeldungen bekommen
reconnect und beim caldav den Abruf ausgeführt -> keine Daten auf den 4 "neuen" Eingängen

Egal ob digital oder analog, bei alle Eingängen habe ich den Haken bei digital raus - richtig?

Im udp-log vom MS sehe ich nur "MQTT:Keep in mind loxberry mqtt only sends...."

Testen kann ich am besten mit der Variable
"vitoconnect_heating_dhw_oneTimeCharge_active" , diese hat nur 0/1 und ich kann die Sofort-Anwahl Warmwasser sehr gut über die Viessmann-App schalten, im Mqtt änderst sich der Wert auch nach ca. 10s, im MS bleibt alles auf "0"

Wie in 565.1 beschrieben ausgeführt
siehe screenshot

[Christian Fenzl]

Bist du sicher, dass der in LoxBerry eingestellte Miniserver-Benutzer Rechte auf deine VI's hat?
In Loxone V11 haben sich die Standardrechte bei neuen Elementen geändert. Der User muss Zugriff auf die VI's haben.

[HRA]

So das war der richtige Tip.
Ich habe >3 Wochen gesucht, aber an den sch... Rechten habe ich nicht gedacht, da ich loxberry Adminrechte gegeben habe.
Nur die Adminrechte werden beim erstellen des VI nicht eingetragen - Asche auf mein Haupt
Vielen Dank für deine Bemühungen -> DKMS hat sich egrade gefreut :-)

Bekomme jetzt alle Daten im MS02 rein mit der pipe "|2" :-))))

[Tico]

HRA and Christian Fenzl - One thing has me confused. That is the choice to use either a Virtual Text Input or a Virtual Input in the Config.

I am currently using only Virtual Text Inputs for both numeric data and text data. If I use a Virtual Input for a single numeric input, I get no response in the Miniserver. A Virtual Text Input works fine for the single numeric transfer.

Is this what HRA is seeing?

[Tico]

Yes, that is understood and already implemented. Use as digital input - unchecked. I don't get any data still with a Virtual Input.

Name of Virtual Input - robonect_mower_statistic_hours, digital input unchecked.

Result in Miniserver = 0

Name of Virtual Text Input - robonect_mower_statistic_hours

Result in Miniserver = 32 (which is correct)

[Tico]

Sorry, disregard the previous entry. I've now re-entered the subscription, re-saved, rebooted. It has just started working with what I'm sure I already had set...
Gremlins.

[Christian Fenzl]

LoxBerry‘s IO to the Miniserver uses caching. Same values aren’t sent twice.
Saving the plugin config will disable the cache for the first submission.
There’s the button in the UI to resubmit - that will trigger also to delete the cache and resubmit everything if it is received the first time after hitting the button.

[HRA]

Habe aber noch eine Frage bzgl. setzen eines V-Ausgangs

Der zugehörige VI heisst
vitoconnect_heating_dhw_oneTimeCharge_active
dieser hat den Wert 0 oder 1
Ich möchte nun von Lox aus diesen triggern, z.B. über einen EIB-Schalter
Wie muss der Ausgangsbefehl sein?

Als Vorlage habe ich diesen genommen (der funktioniert, war glaube von , habe es aber nicht hinbekommen
/admin/plugins/Vitoconnect/vitoconnect.php?action=setvalue&option=heating.dhw .temperature&value=<v>

[Christian Fenzl]

Das ist eine URL des Vitoconnect-Plugins. Da kann ich dir leider nicht weiterhelfen.

[HRA]

Habe heute Nacht diese Meldung vom MQTT erhalten - MQTT requestet to STOP
In Conversions habe ich aber nichts programmiert, hatte gestern einen Versuch gestartet, dies aber wieder gelöscht und "Save" and "restart" gedrückt
Weshalb greift er dann noc auf die Conversion zu, die sind ja leer.
Muss ich da noch etwas machen, sollte doch eigentlich damit alles wieder gelöscht sein?

hier Auszug aus Logfile:

[HTML]
06:56:40.137 INFO: MSNR: 1

06:56:40.137 INFO: UDPPort: 11883

06:56:40.137 INFO: Connecting broker localhost

06:56:40.138 INFO: Login at broker

06:56:40.138 INFO: Sending Last Will and Testament
06:56:40.148 Subscription caldav4lox/events/#
06:56:40.148 Subscription vitoconnect/#
06:56:40.150 Uniquify subscriptions: Before 2 subscriptions
06:56:40.150 Uniquify subscriptions: Afterwards 2 subscriptions

06:56:40.150 INFO: Checking subscriptions for invalid entries

06:56:40.150 INFO: Ordering subscriptions by topic level

06:56:40.150 INFO: Reading your config about what topics to send to what Miniserver

06:56:40.150 INFO: Subscribing caldav4lox/events/#

06:56:40.155 INFO: Subscribing loxberry/mqttgateway/#

06:56:40.159 INFO: Subscribing vitoconnect/#

06:56:40.168 OK: Processing conversions

06:56:40.168 INFO: Adding user defined conversions

06:56:40.168 INFO: Adding plugin conversions

06:56:40.168 WARNING: Ignoring conversion setting: (a part seems to be empty)

06:56:40.169 INFO: Processing Reset After Send

06:56:40.169 INFO: Adding plugins Reset After Send
06:56:40.169 Creating udp-in socket

06:56:40.170 OK: UDP-IN listening on port 11884
06:56:40.170 Creating udp-in socket

06:56:40.170 OK: UDP-IN listening on port 11884

06:56:40.276 INFO: MQTT received: loxberry/mqttgateway/status: Joining
06:56:40.277 loxberry/mqttgateway/status is cached
06:56:40.277 HTTP: Preparing input loxberry_mqttgateway_status (using cache): Joining

[Christian Fenzl]

Ich glaub, ich hab die Pointe verpasst - was genau ist das Problem?

[HRA]

Das ich diese meldung vom MQTT erhalten habe, gelber Hinweis im Log
ich aber in coversions nichts programmiert habe
Wie gehe ich damit um, wo sehe ich " welcher Teil leer zu sein scheint"