LoxBerry MQTT

[svethi]

You show us the Shelly topic. You show us the parts of the VI config. You show us the log from the miniserver. You are reporting us problems with your program but you don’t show us your program. How should we help you?

[Christian Fenzl]

It is 12ms delay between on and off.
Does the tracker collect such short timings?

Have you tried a Monoflop after the VI with one or two seconds delay, and track this?
You may only have used „online“ for testing. For production, Reset-After-Send makes no sense for the online state.

[Aleq]

Hi svethi , Christian Fenzl,
thanks for your time. I thought/hoped the delay theory would be sufficient enough. I did not dare to think you'd want to go that deep. Thanks, here it is:

Subscriptions:



Loxone Config program, screenshot captured 14 seconds after the HTTP REST has been triggered. Monoflop has 30s cooldown, yet it's off. No notification in tracker, nothing in mailbox. It really did not get recognized


MQTT Explorer showing history of those messages:


This is a part of the program responsible for querying the status every 60 seconds


And this is after several tries (I have manually sent "shellies/command": "update") - about 3rd response got recognized by Loxone:



Regarding:
> You may only have used "online" for testing. For production, reset-after-send makes no sense for the online state.
Is it not acceptable way to monitor the connection of shelly devices? Request connection status every minute and then to have a "Switch off delay" with 130 seconds (perhaps more to allow false alarms on temporarily lost wifi connections) triggered by "connect" message?

Thanks, Best regards,
Aleq

[Christian Fenzl]

Online state: It is Shelly’s LWT topic (Last Will and Testament). The Broker will set the LWT topic to offline when the connection is dropped.
Therefore, no Reset-After-Send is required. It will go to “Offline” (convert it to 0) if Shelly dies.
Try it by disconnecting Shelly from power.


If the delay is to short for the Miniserver, it requires some rework in the plugin.

@All: Would be nice, if someone else using Reset-After-Send could say something about this.

[Aleq]

Beautiful, it works (in MQTT explorer). I was not aware of LWT. I'll try it in Loxone Config, I assum it resolves this issue for me as I'll abandon the Reset after send.
I'll keep this part in my code should you need me to test this, though.

Thank you

[Aleq]

Christian Fenzl
If you want me to test with greater delay (before Reset), point me please to the source file and line number and tell me what should I put there (sleep(1)?). I can "hack" it directly in the plugin folder on the Loxberry and test it with my Miniserver.

[Christian Fenzl]

The MQTT Gateway itself has an LWT. It’s <hostname>/mqttgateway/status
In MQTT Explorer you’ll see it changing if you kill mqttgateway.pl.

Unfortunately, no-one would submit this message to Loxone 🤪
Therefore, to check the Gateway, the keepaliveepoch is there, sending it’s timestamp every minute.
You need to check this for change (see wiki).

[Aleq]

I have that as


maybe a bit over-engineered, well... :-)

1) I don't need the reset after send anymore thanks to your LWT suggestion, but I offered myself as a tester - if you want to debug that "Reset after send", I can add sleep(1) into the code (if you guide me to which line) and retest it with my setup - to see, if it helps. If yes, we'll know the delay between two commands is sensitive topic. If not, it's the Loxone bug perhaps, or I don't know.

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?


Best regards,
A.

[svethi]

Normaly you don’t need to reset after send if your VI is set to digital. In digital mode the VI only triggered an impuls.

[Aleq]

I have it as a digital input, yet that online "1" lights the virtual input and it stays lit until "0" comes. Plus I believe the primary purpose of "Reset after send" functionality was for push buttons, which are also digital. Or am I missing something?

I have switched to LWTs, but it's not working if the device disconnects during Loxone restart (or complete power outage throughout the whole house I guess)

Thanks,
A.

[Christian Fenzl]

Issue for the Reset-After-Send delay
https://github.com/christianTF/LoxBe...eway/issues/43

[Christian Fenzl]

See this example for a “non-over-engineered” change recognition: https://www.loxwiki.eu/pages/viewpag...pageId=9339459

Use Google Translate 🙂

If there is no pulse for e.g. 120 seconds, the Gateway is dead.

[Aleq]

I know this change detection already (from here, from you https://www.loxforum.com/forum/softw...g-value-change - it is ingenious, by the way), but did not think of it in this process. Instead I calculated how long time has passed since last keepalive... This involved painful timezone difference calculation to the UTC, etc... Jesus!
https://en.wikipedia.org/wiki/KISS_principle

Thanks

[Christian Fenzl]

As I needed to fix an utf8 issue with udp transport, I just implemented the delay.
Install the master https://github.com/christianTF/LoxBe...ive/master.zip
After installation, in the configfile mqtt.json you'll find a setting Main.resetaftersendms
This is the delay in milliseconds the Gateway waits before sending the 0.

After changing and saving the configfile, no restart of the Gateway is required. The restartaftersendms delay is logged.

You can play around with the value. It would be cool to have the lowest possible value that ensures transmission, to have a default value for the next (pre)release.

lg, Christian

[Aleq]

Hi Christian Fenzl,
a small spark of genius, how about sending directly a Pulse instead?

http://loxone/dev/sps/io/shellies_shellyplug-s-51CC26_online/Pulse

I have tested it locally and it worked for me all the time.

Best regards,
Aleq

[Christian Fenzl]

Not possible as inputs may need analogue values with conversation.

Think of a switch device, that sends „Click“, „Double click“, „Long Click“, or „Up“ and „Down“.

I would prefer if you test the change I‘ve implemented from your issue.