-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a way to immediately publish telemetry? #2567
Comments
Hi, You can use rule as explained on the wiki |
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. |
Use |
I'm more interested in the esp publishing it early rather than just viewing it. I'll fork and make a change later. |
The background to this is that I want to provide a refresh button on an mqtt dashboard that will update the telemetry values |
I dont understand why status 8 is not the solution for you. |
Because my widgets are subscribed to tele/sonoff/sensor |
I'm going to re-read the mqtt docs in case I've missed something really basic! |
Hi, To do manual updates you can use the mqtt broker configuration as explained on https://github.com/arendst/Sonoff-Tasmota/wiki/Home-Assistant |
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. |
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. |
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. |
Root of the issue is: Message format and MQTT topic are different on Response of telemetry period:
Response of
Consequence: Use case: Possible improvement: Note: Similar issue is #1032. |
Hi, already fixed. Please update to latest Tasmota. Thanks |
Hi, Please, could you send me any information how telemetry data is being sent, after power toggle? No status 8. Best regards Mark |
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. |
@ascillato: Looks still not fixed. The command Workaround: |
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 |
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: 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. |
Seems that |
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. |
So, you want a command like the one you are using ( |
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. |
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? |
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. |
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. |
Publish teleperiod data on command ``TelePeriod`` (#2567)
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 = 0 DO |
You don't need to specify a period. Using just command 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 ? |
Thanks. I've had success testing the following based on your suggestion. Rule1 ON ENERGY#Power = 0 DO rule1 1 |
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?
The text was updated successfully, but these errors were encountered: