Is there a way to immediately publish telemetry?

[Stevehans]

I've had a quick look and it seems that the telemetry is only published when the tele_period expires, is there a way to force an immediate (or almost immediate) refresh of telemetry?

A command to set tele_period to Settings.tele_period -1 I think?

[ascillato]

Hi,

You can use rule as explained on the wiki

[Stevehans]

Not sure how unless I've missed something, the only call to publish the telemetry is when tele_period is incremented and equals Settings.tele_period?

How would this be done other than by doing individual publish commands to equate to the telemetry output?

I think there needs to be a code change to implement telemetry_refresh that would set the tele_period to Settings.tele_period -1 which would then cause all the actions to occur.

[arendst]

Use status 8 to retrieve the telemetry data at command.

[Stevehans]

I'm more interested in the esp publishing it early rather than just viewing it.

I'll fork and make a change later.

[Stevehans]

The background to this is that I want to provide a refresh button on an mqtt dashboard that will update the telemetry values

[Jason2866]

I dont understand why status 8 is not the solution for you.
You fire this command with your refresh button and you get immediatly the actual values of all sensors
as a mqtt (Json encoded) Status 8 result

[Stevehans]

Because my widgets are subscribed to tele/sonoff/sensor

[Stevehans]

I'm going to re-read the mqtt docs in case I've missed something really basic!

[ascillato]

Hi,

To do manual updates you can use the mqtt broker configuration as explained on https://github.com/arendst/Sonoff-Tasmota/wiki/Home-Assistant

[Stevehans]

Ok, I can see what you're saying, that's fine for say OpenHAB, but the android dashboard takes one subscribe per widget.

I'll fork and add the code I need to achieve this then do a PR.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.

[ma-zal]

Root of the issue is: Message format and MQTT topic are different on Telemetry period event and when sonoff1/cmnd/STATUS 8 called.

Response of telemetry period:

• MQT: sonoff1/tele/SENSOR = {"Time":"2018-12-24T21:01:23","AM2301":{"Temperature":22.0,"Humidity":42.7},"TempUnit":"C"}

Response of STATUS 8 request:

• MQT: sonoff1/stat/STATUS8 = {"StatusSNS":{"Time":"2018-12-24T21:02:03","AM2301":{"Temperature":22.1,"Humidity":42.9},"TempUnit":"C"}}

Consequence:
Home Assistant application is subscribing one topic only (the telemetry period event response). So when the information comes to different MQTT topic, it will be ignored by subscriber.

Use case:
I would like to enforce the telemetry data when Home Assistant will be started.
Sometimes user did not want to wait for first regular data, which are sent by telemetry period every 5 minutes).

Possible improvement:
It will be nice to implement some command that will fire the exactly same event as is executed on telemetry period (called every 5 minutes as default).
So it will be nice to implement something like sonoff1/cmnd/TELEMETRY.

---

Note: Similar issue is #1032.

[ascillato]

Hi, already fixed. Please update to latest Tasmota. Thanks

[markross42]

Hi,
I have the same sort of requirement. And I could not find any solution.

Please, could you send me any information how telemetry data is being sent, after power toggle? No status 8.
(using: tasmota 6.7.1)

Best regards

Mark

[meingraham]

If a shorter TelePeriod does not meet your need, Rules as posted on Google Groups.

Otherwise modifications to the code by forking the repository yourself.

[ma-zal]

@ascillato: Looks still not fixed. The command STATUS 8 is returning incorrectly into mqtt topic .../STATUS8. But we are expecting topic .../SENSOR to correct understanding by Home Assistant.

Workaround:
If you set TelePeriod (you can update to same value as current), then Tasmota sends .../SENSOR immediatelly. So command TelePeriod 300 will response all sensor data.

[ascillato]

I don't know how exactly is your setup but seems for your request that you are not using Tasmota as was designed. Please, address this to the Tasmota support chat to discuss your setup and how to implement it

[sep-don-barrett]

Here's the use case, which I have too: I need to get rapid updates for certain sensor changes to homeassistant, and have to do a workaround with rules like:
on ENERGY#Current>0.100 do TelePeriod 60 endon

Ideally one would simply use another Status command have the same SENSOR(as opposed to STATE8) MQTT publishing ordinarily done, to avoid changing various clients down the line, and to have to hardcode the existing teleperiod. It's the need to push time-critical updates using the usual notification mechanism. Another alternative is a special Teleperiod code to force the update without changing the existing teleperiod.

Seems a very common use case, as push-updates are a common mechanism in control systems.

[ascillato]

a special Teleperiod code to force the update without changing the existing teleperiod.

Seems that teleperiod 1 command is what you are looking for.

[sep-don-barrett]

teleperiod 1 resets the interval to the firmware default. I'm suggesting the payload of a rule to force the teleperiod sensor update manually, just as switch operations are pushed at the time of change. The teleperiod reset to force SENSOR broadcast over MQTT I'm using now has to be hardcoded to what I'm otherwise using as the teleperiod of the device, and changed along with that teleperiod should I choose a different one.

[ascillato]

So, you want a command like the one you are using ( TelePeriod 60 ), but that will not reset the counter of teleperiod?

[sep-don-barrett]

Yes, that will push sensor data immediately in the same way as it is normally done, for when conditions are met for which the subscribers have an immediate need to know. It could be as simple as having "status 8" send a SENSOR broadcast, or having another status or teleperiod argument that triggers the same.

[ascillato]

Ok. Got it.

Question. The command teleperiod 60 that triggers the tele message and start counting again from 0 up to 60 to send another teleperiod, why is not good that teleperiod time reset in your setup?

An option can be a new argument for teleperiod, like teleperiod 2 to trigger a tele message without resetting the counter. What do you think?

[sep-don-barrett]

Locally, there's nothing bad about it, it meets my need. But from good engineering design, it forces the operation to have an unwanted side effect, namely losing the prior value of teleperiod unnecessarily, which has nothing to do with the operation actually sought. For instance, if I decide that to change the heartbeat teleperiod of a sensor for non-time-critical monitoring, I'd have to change the rule statements for the time-critical pushes, a fragile operation if one is building a larger system based on these concepts, given heartbeat sensor monitoring and time-critical sensor monitoring are somewhat orthogonal in their configuration needs.

By the way, my enormous appreciation for the incredible resource Tasmota has grown into, given the ubiquity of the ESP8266 family in inexpensive consumer devices.

[Kedryn]

Just came here because i was looking for the same thing. A way to manually force a telemetry message, without changing the telemetry value.

I have, for example, a meteo station outside in the garden, that has several sensors (temp, humidity, pressure ,light). It has also a rain sensor via analog value. My telemetry is set to 10 minutes, but if starts raining, i need read the rain sensor as quick as i can (like 5 seconds)

Right now i have a rule that, if the analog value changes, when is 1024 it sends a teleperiod 600, if it's lower than 1024, it sends a teleperiod 5.

The problem is that if, one day, i need to have a teleperiod of 300, and i set it via de console, as soon as it rains, it will go back to 600.

The same goes for my temperature sensor under the freezer door to check if someone forget it opened (no, a door sensor would not be enough if the freezer door is opened only a bit like few millimeteres. It wont report that)

If we can have, like a "teleperiod -1" that does not change the actual value but only triggers it, it will be much usefull.

[arendst]

#2567 (comment)

[githubuser9999999]

I know this is an old thread, but how about just setting the teleperiod as a part of a rule when some threshold is passed and then setting it back when it crosses back. Something like this...

Rule1
ON ENERGY#Power > 5 DO
TelePeriod 10
ENDON

ON ENERGY#Power = 0 DO
Teleperiod 300
ENDON

[barbudor]

You don't need to specify a period. Using just command Teleperiod will trigger a telemetry message as soon as possible
You can also use Status 10 which is slighly different as it has an additional level in the JSON.

You can also forge your own message and publish it directly through the rule.

Regarding Energy, have you explored all the possibilities of PowerDelta and Margins ?

[githubuser9999999]

Thanks. I've had success testing the following based on your suggestion.

Rule1
ON ENERGY#Power > 2 DO
TelePeriod
ENDON

ON ENERGY#Power = 0 DO
Teleperiod
ENDON

rule1 1