Can Tasmota make UDP calls?

[smalcz]

Hello there,

I am running Tasmota on a zigbee gateway, and planning to connect multiple ZB switches to it. These switches, when pressed, send the "pressed" info into the Tasmota gateway. Now I need to take this information and send it to my home automation server (Loxone).
Loxone works great with UDP packets. Is it possible to configure the Tasmota gateway to make a UDP call (send a specific number or command) to a specific IP address?

Many thanks!

[barbudor]

If your gateway runs on an ESP32, you can use the Berry language which supports UDP

If you are on ESP8266, the only way is to write a native driver as there is no generic UDP feature in Tasmota

[smalcz]

ESP32 it is, happy to hear that, thank you!

[s-hadinger]

Then it should be easy. See https://tasmota.github.io/docs/Berry/#udp-class

[smalcz]

Seems that due to the syslog delay my only hope would really be Berry. (Loxone does not have MQTT support and I do want to avoid the workarounds that are available).
Pardon the Berry newcomer question: how could I write a Berry "rule" to forward a ZbReceived event to a specific IP via the UDP call? I have for example such events from a simple zigbee switch:
19:52:41.336 RSL: SENSOR = {"ZbReceived":{"0xA9F7":{"Device":"0xA9F7","Name":"zbSwitch01volume","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":107}}}
Anytime I have a Power:2 event, I would like to do a u.send("1.2.3.4", 1234, bytes().fromstring("zbSwitch01volume")).
Any help would be appreciated!

[sfromis]

First, I'd recommend using options for a more practical JSON format, like ZbNameKey for using the ZbName value as key instead of the opague "short address" (which is not repeatable if creating a new network), and maybe ZbNoPrefix for dropping the `ZbReceived level from the JSON.

That would change your payload
{"ZbReceived":{"0xA9F7":{"Device":"0xA9F7","Name":"zbSwitch01volume","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":107}}}
to
{"zbSwitch01volume":{"Device":"0xA9F7","Name":"zbSwitch01volume","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":107}}

In both cases, you can use triggers to react the the JSON, like zbSwitch01volume#Power==2 or ZbReceived#0xA9F7#Power==2

One way of handling that in Berry could be

def forwardReceived(value, trigger, data)
  u.send("1.2.3.4", 1234, bytes().fromstring("zbSwitch01volume"))
end
tasmota.add_rule('zbSwitch01volume#Power==2', forwardReceived)

And then to expand on it from there. The data argument is the JSON parsed into a map structure, where all fields are available. Obviously, you still need to have done initialization for UDP. If you want it to be for multiple devices, you can also use wildcards in the add_rule trigger.

[Noschvie]

@smalcz why are you not using MQTT ?

[smalcz]

@s-hadinger Sorry I was not precise. Not only the weblog console (thanks for the explanation!), but also in Loxone the messages arrive with a delay. I was wondering if it was due to the fact that also Syslog on Tasmota has a delay. If that was the case, maybe a berry rule with a dedicated udp message could be faster.
@sfromis indeed! I will try mqtt just to check if it is faster. Just don't want to use it as a final solution for the reasons mentioned above. I dont need to blink a led, because I know for sure that the message arrives in Loxone quite late.

[s-hadinger]

No syslog has no delay. If you see a delay, it must indicate something wrong in the configuration.

[arendst]

Except serial logging all Tasmota logging output is delayed to return to the scheduler asap.

Both MQTT logging MqttPublishLoggingAsync() and syslog logging SyslogAsync() are provided at a second interval. GUI logging is provided at WebRefresh interval. Providing immediate logging would delay time critical code execution severly.

[sfromis]

I was not talking about a "final solution", only about methods to get a feel for timing, which the web UI does not give you. The point was that you'd get an indicator of where Tasmota actions are in the time span of the latency you see.

[smalcz]

@arendst Many thanks for the confirmation, at least I know that it is a hard-coded feature and not a setup issue on my end.
Is there any possibility that this scheduler delay could be configured?

[budulinek]

Except serial logging all Tasmota logging output is delayed to return to the scheduler asap.

Both MQTT logging MqttPublishLoggingAsync() and syslog logging SyslogAsync() are provided at a second interval. GUI logging is provided at WebRefresh interval. Providing immediate logging would delay time critical code execution severly.

I know that Syslog (UDP) was not meant to be used this way, but Syslog is a great alternative to MQTT. Easy to set up, fast, efficient, formated (JSON).... I use it for a direct Tasmota (ZigBee) -> Loxone communication. And I have even written a tutorial for others to follow: https://www.vodnici.net/wiki/zigbee-pres-tasmotu-1-hardware/ (in Czech).

For me (@smalcz and others who follow my tutorial), SyslogAsync() is THE time critical code. I understand your desire to return to scheduler ASAP. But since UDP is stateless, the delay caused by syslog is minimal. Actually, there could be some delay (tens of millisecs) if syslog host does not exist. But this delay can be eliminated by using UDP broadcast (syslog host 255.255.255.255).

I have checked the code and SyslogAsync() is called by PerformEverySecond(). Would it be possible to call SyslogAsync() immediatelly in Scheduler() in case of UDP broadcast (syslog_host_addr equals 255.255.255.255)?

Thanks a lot!

[barbudor]

Syslog, like Weblog, SerialLog are debug features that are not meant to be used as operational features, so it is unlikely they will be ever prioritize over MQTT which is the operational protocol chosen for Tasmota, and many other home automation solutions.

On the receiving side, parsing syslog is much more complicated than processing MQTT messages to.

You are trying to use a hammer with a screw.

[Noschvie]

In case of using Loxone MS and Tasmota devices a LoxBerry is a "must have" and very easy to use.

[smalcz]

@Noschvie I do have Loxberry but it is just another potential point of failure. UDP is faster, more simple and works without a middle man. I do agree that sending the whole syslog may be an overkill, but it depends on the use case and the exact setup (I don't have much noise in Tasmota's syslog for example). But my preference would be to generate only the specific UDP calls using Berry, if I can wrap my head around it.

[budulinek]

I know that syslog was not meant to be used for "operational" purpose and I acknowledged that in my previous post. But even if you use syslog for debugging, you would not expect an artificial 1s delay.

@s-hadinger did not expect a delay on syslog. I did not expect a delay on syslog. I have spent a huge amount of time trying to figure out the source of the delay, trying different configurations, compile options and even ZB radio firmwares. It did not cross my mind there could be an artificial delay on syslog itself.

My main point is that syslog (UDP) execution is very fast and fears about syslog "severely delaying" code execution are misplaced.

So I have a humble question for @arendst :

• Would you agree to call SyslogAsync() directly in Scheduler()?

Taking into consideration that:

• Syslog is off by default and the proposed change will affect only those users who deliberately enable syslog.
• Users who enable syslog (either for debugging or "operational" purpose) do not expect syslog to be delayed.

Thank you very much!

[sfromis]

The concerns about delays are not related to what happens on the network, but about not making blocking calls in the middle of the important code flows on a single-threaded setup without asynchronous operations (outside of interrupt handling), like ensuring that core features like device control and MQTT are well-served. Depending on log level, syslog can get a lot more busy than MQTT. And the rarity of questions about syslog indicates that this is not a much used feature, and especially not with a real-time expectation. Logs are for storage and later review, not for misusage as transactions. Anyway, UDP is not meant for transactions of significance, unless wrapped in a protocol to handle errors, which are no rarity on Wifi.

[budulinek]

The concerns about delays are not related to what happens on the network, but about not making blocking calls in the middle of the important code flows on a single-threaded setup without asynchronous operations (outside of interrupt handling)

Of course, I know what I am talking about (a single-threaded setup) and I know about your concerns. I was not referring to what happens on the network. I was explicitly talking about the speed of code execution. Sometimes "what happens on the network" has an impact on the speed of code execution (some libraries have blocking calls for TCP timeouts and resends). But that is not the case here with UDP. I have checked the code and I see no dangerous blocking calls:

Tasmota/tasmota/tasmota_support/support.ino

Line 2309 in 625b204

void SyslogAsync(bool refresh) {

https://github.com/esp8266/Arduino/blob/fb8d6d668df95e138d6248e7239cbf98c77f8174/libraries/ESP8266WiFi/src/WiFiUdp.cpp#L141

Depending on log level, syslog can get a lot more busy than MQTT. And the rarity of questions about syslog indicates that this is not a much used feature, and especially not with a real-time expectation.

Syslog is off by default. I assume that if someone enables syslog with high levels (rarely happens as you have noted), (s)he is doing that on purpose and (s)he wants (and expects) syslog to be a lot more busy than MQTT.

[pkkrusty]

Any further progress on this? Seems like a worthy option for folks needing to get data out quickly/predictably.

[pkkrusty]

Sorry I was replying to the latest post from @budulinek where he asked arendst if he would consider moving the UDP call into the main thread to avoid delays. Wondered if OP had made any progress or forked his own binary.

[budulinek]

Hi @pkkrusty,
here is my fork:
https://github.com/budulinek/Tasmota

and here is my pull request to bring realtime syslog to upstream:
#20260

The changes to the code are minimal. Just changing 2 lines of code...

[smalcz]

Have been using @budulinek 's fork happily for a month now, works like a charm. @arendst : If performance concerns are behind your reluctancy to accept the unconditional realtime syslog udp calls, could you consider making it a configurable option?

[s-hadinger]

There are many topics discussed in this thread. What is your question?