LoxBerry MQTT

[Aleq]

Hi Christian Fenzl
,
I see, true, true.
It would make sense only on certain messages, ie. it would require additional (new) option under advanced table information, something like "Send pulse on 1"? This may require more thinking, which values to trigger a pulse... Is it worth it? Don't know, will leave this to you.

Regarding your latest build and delays - I have tested your latest build, thanks for it.
It starts to improving things at about 4ms. It looks almost completely reliable at 8ms, but then there's suddenly a couple of messages were lost. (I have observed it for couple of minutes only):

10ms looks great, but it may require longer testing.

I'm worried if this value is valid everytime and for everyone, if it's universal safe value. What if it depends on the miniserver CPU load or similar? This could mean even if we settle with let's say very "safe" value of 20ms, there may be circumstances when it's still not recognized.

By the way, does this apply only and only to two messages for the same virtual input, ie. if 2 different MQTT messages (for 2 different virtual inputs) come at the "same" time, do they get recognized? Do you know? We may want to test this as well.

Regarding https://www.loxforum.com/forum/proje...002#post232002

2) I have noticed that neither "reconnect" UDP command nor "Retransmit all data (for testing)" button in the plugin ui won't resend the "connect" topics. Is it because of LWT? Is it intentional?

Is it intended or should I open a bugreport at github?

Cheers,
A.

[Christian Fenzl]

Retransmit: Current Implantation only retransmits RETAIN messages, as retransmit does a re-subscription. If the LWT from Shelly isn’t coming in on subscription, that would be a bug of Shelly, I think.
This could be verifyed by mosquitto_sub if it comes in.

The resetaftersendms delay only is used if a resetaftersend topic is coming in. If nothing comes in, no delay takes place.

Incoming MQTT messages are queued by design of the broker. The plugin need not to queue the incoming messages. The delay takes place on a per message basis. Two messages on the same topic therefore are handled in the correct order (1-0-1-0, has two delays).
With two topics it would send
t1: 1-delay-0
t2: 1-Delay-0

It‘s a bit different if json is submitted. As a bunch of values may come in in one mqtt message.
For the SAME topic with two messages, still 1-0-1-0 with two delays take place.
If json submits TWO DIFFERENT subkeys that have reset-after-send set in ONE json message, it looks like this
t1: 1
t2: 1
Single delay
t1: 0
t2: 0

So it is implemented to always have the correct order, and at least one delay.

I don’t know if there are differences of Miniserver processing with different configurations (eg MSv1 vs. MSv2). Therefore, the value is not hardcoded but a Config file value.

[Aleq]

Hi Christian Fenzl,
checked, online message (LWT) indeed does NOT have retain flag. That's the reason then. I have asked Shelly people if there is any chance they could set it... let's see.

Clear about the order or messages, (although the JSON stuff is interesting). Thanks for the explanation.
You may have misunderstood my hypothetical question about Loxone interpreting 2 HTTP RESTs received very shortly one after another, though. We have noticed 1 and 0 for the same virtual input may be lost (skipped), if they arrive via HTTP REST very close to each other (timewise). It may be indeed be caused by internal processing within same processing time-slot (Loxone "tick"). But this is only our theory, so I wanted to bring to the table the question, does this happen to 2 shortly consecutive messages for the SAME virtual input ONLY? And if there are two HTTP RESTs setting one virtual input to 1 and the other (different one) also to 1 (ie. we are talking about 2 completely different virtual inputs), within same short timeframe, is Loxone handling it properly this time? I volunteer to a test, if you don't know the answer, as this may be useful to know for your plugin as well.

Cheers,
A.

[Christian Fenzl]

Another delay comes in place, having impact especially on reset-after-send:
If you send two messages with 1, you‘ll get
1-Delay-0-pollms Tick-1-Delay-0-pollms Tick
The timeframe between the 0 and 1 is controlled by the gateway „tick“ with pollms delay.
It takes place for every message.
pollms defaults to 50 ms (mqtt.json file) and is a self-defined „don’t flood the Miniserver“ delay. For the gateway load, it does not really make a real performance impact if using eg 10 ms, but 50ms should be long enough to protect MS load.

I‘m currently in Alexa project and aren’t at will doing into-deep analysis.

You may try a small script with LoxBerry SDK mshttp_send to try how MS behaves:
https://www.loxwiki.eu/display/LOXBE...%3Amshttp_send
During request loss, would be interesting what MS responds.
mshttp_call also returns the full response of the Miniserver: https://www.loxwiki.eu/display/LOXBE...%3Amshttp_call

lg, Christian

[Gast]

Good evening.

I made a lot of test but I still have problem with delays. After switch ON from loxone app shelly need around 10s to swich ON the light. The same time is for switch OFF. I tested inputs too. Inputs works perfects, maybe same milliseconds of delay. Maybe is reason on router? I have raspberry connected direct to router HUAWEI B315 with ethernet cable. I didn't change any parameters on router.

Regards.
Jery

[Aleq]

Check if your Shelly responds timely via its own web page
(here:

)?

If this responds timely, check MQTT, for instance via (http://mqtt-explorer.com/) - does it respond timely if you send the command to switch it on / off?

yes, on shelly respons timely.
I checked with mqtt-explorer, like I said in previous mail, cca 10s need signal to MQTT.
Any idea?

[Christian Fenzl]

Check the Gateway log, if the udp Input appears timely.

[Gast]

Here is a log file, same situation, cca 10s. When I heard relay I timely change the state from on/off or on/off.

[Aleq]

Another delay comes in place, having impact especially on reset-after-send:
If you send two messages with 1, you‘ll get
1-Delay-0-pollms Tick-1-Delay-0-pollms Tick
The timeframe between the 0 and 1 is controlled by the gateway „tick“ with pollms delay.
It takes place for every message.
pollms defaults to 50 ms (mqtt.json file) and is a self-defined „don’t flood the Miniserver“ delay. For the gateway load, it does not really make a real performance impact if using eg 10 ms, but 50ms should be long enough to protect MS load.

50 ms sounds safe enough indeed.

Still, I have performed the test to have a better understanding of Loxone behavior. Seems that Miniserver (v1 with 8.3.3.21, YMMW, newer versions (9.x, 10.x) on MSv1 are known to perform worse AFAIK) handles higher load without bigger issues. At least on my 5 virtual inputs manipulated in sequence as fast as possible (some test attempts were just 1ms from each other), it worked reliably.

I have performed

 for i in `seq 1 5`; do
curl http://$USER:$PASS@192.168.1.77/dev/sps/io/viperf_$i/$num &
done

many times in the row.

The timing on Loxone was like:


This is good news. That issue I have discovered with skipped messages really relates ONLY to fast consecutive manipulation of the SAME virtual input.

[Christian Fenzl]

The log states, from publish to receive it back from the broker, are 70ms.
This is a broker<->Shelly problem.

Of course, I don’t see the delay from Miniserver button press to gateway UDP receive, but you would see the delay if you follow the log. I don’t think there is any.

Thank you for your help. Soo, I have to buy new shelly switch and do it again or you have any better idea?

[Aleq]

I'd suggest to check with Shelly support. I'd not throw it away yet

[Gast]

Hallo Zusammen,

ich habe mich dem Thema MQTT angenommen und zum Test einen Shelly1 eingebunden.
Dabei habe ich mich exakt an die ausführliche Beschreibung im lox-wiki genauer gesagt dem Video gehalten:

https://youtu.be/a0zusnjLAiY

Das hat soweit gut funktioniert.
Danach habe ich die Visualisierung des virtuellen Eingangs für den Status am EIB Taster noch deaktiviert (den möchte ich ja nicht auch noch sehen).

Nun da die Visualisierung deaktiviert ist, wird der Virtual Input nicht mehr vom MQTT Gateway aktualisiert.
Kann das Verhalten jemand bestätigen? Kann man das umgehen?

Danke und Grüsse,
Stephan

[Christian Fenzl]

Das wäre mir neu.
Vielleicht kann das jemand anderer mit aktueller Loxone Config testen, ich habe auswärts kein Equipment zur Hand.

Habe es eben noch mal ausprobiert. Ist bei mir jedenfalls reproduzierbar. Sobald ich die Visualisierung des VI deaktiviere, wird er vom MQTT Gateway nicht mehr aktualisiert.

[Christian Fenzl]

Eben getestet: Nicht reproduzierbar. Loxone V10.3.11.27.
Zeig mal deine Config und die vollständigen Eigenschaften des VI.

[Gast]

Also hier meine config des VIs:


Ich verwende die gleiche Loxone Version.

[Christian Fenzl]

Schaut richtig aus.
Liegt der VI jetzt einfach „blank“ auf einer Seite?
Probier mal, Kategorie/Raum zu setzen.

[Gast]

Hallo Christian,
vielen Dank für deine Bemühungen und Ideen!

Das Ergänzen von Raum und Kategorie hat aber leider auch nichts gebracht.
Der Eingang hängt am EIB-Taster:

Habe auch schon probiert die Visualisierung zu aktivieren (Häkchen gesetzt), bei erlaubte Benutzer (lokal/Internet) dann "Niemand" ausgewählt. Gleiches Ergebnis, der Eingang wird nicht aktualisiert. Ich werd noch verrückt.

Ich werde das gleich mal noch mit einem fhem Reading ausprobieren, das nun auch über MQTT Gateway kommt, ob dort das Gleiche zu beobachten ist.

[svethi]

Also erlaubte Benutzer Niemand, funktioniert ja schonmal nicht.

Das war ja auch nur eine Idee zur Unterdrückung der Visualisierung des VIs (also ein workaround).
Hat aber auch nicht funktioniert...
Sobald der VI nicht mehr in der Visualisierung sichtbar ist, wird er auch nicht mehr aktualisiert.

[svethi]

Probiere doch mal einen anderen Weg. Lege einen Benutzer im Miniserver an, der für den Loxberry gültig ist und setze die Zugriffrechte des VI NUR auf diesen Benutzer. Andere User sollten den dann nicht sehen, aber für den Loxberry User ist er da

[Christian Fenzl]

Häng den VI ab, dass er alleine auf der Seite liegt.
Dann VI zurücksetzen auf Alle/Alle.
Dann speichern in MS mit LiveView.
Shelly aus, Shelly Ein. Screenshot.
Ich seh den Status bei dir ja garnicht, weil’s keine LiveView ist.