-
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
Telemetry with Uptime only #4
Comments
Can't you do some testing on the JSON fields you receive and want to act upon? In case of a Sonoff Pow you'll get two TELEMETRY messages with different fields so that would also be a problem in your case.
|
I see the same issue in logs: _tele/sonoff1/TELEMETRY = {"Time":"2017-01-30T10:02:30", "Uptime":1} Uptime is sent on every hour at 2:30 and full status at TelePeriod time |
As designed. Even if teleperiod is 0 you'll receive the uptime message every hour as a kind of heartbeat to be used as trace information. |
This build will only support MQTT JSON messages in the future? |
Additional filtering on the message content is absolutely possible. What I'm trying to promote is a "fixed data set per topic" approach. As a 2nd option I want to mention what is already in place for RESULT topic, where "Info1" and "Info2" are used to distinguish between 2 data sets. |
@klond Yes, this build will only support MQTT JSON except for the power on/off which will also send messages like @evilgreen The advantage of JSON is that a fixed dataset is not needed as all messages are labelled with their unique label. The telemetry data will change depending on what sensors you connect to your sonoff. |
@arendst Thanks for the information, I understand that JSON have alot of advantages . |
@ThomDietrich Nice job, I was thinking the same.. If we could make some examples for each Sonoff product. Then it would be easier to deploy. |
@klond yes that would be really handy! If you'd like, join me in filling the wiki article as well as the community forum thread. I will add Sonoff Basic, Dual and Pow (hopefully) this evening. |
@arendst I've encountered the "problem" you describe in your first answer. The first TELEMETRY message doesn't contain Power, the second doesn't contain RSSI. I'm parsing for both, seeing the same issues @evilgreen was seeing (using openHAB).
Now, Yes I agree json is great and further information for new sensors or similar can be added over time. I believe we all agree there. Now we could blame openHAB... but it is doing the job just fine. It receives a message and "correctly" reports back NULL as a result of failure. The problem is, that Sonoff-Tasmota sends different datasets in parallel on one MQTT topic. That seems error prone (as proven by openHAB, see above) and isn't really meaningful, because one of the big advantages of MQTT is, that you can define as many topics as you wish. You should seriously consider fixing the set of fields per topic. Topics could be "Status", "Uptime", "Energy", "Telemetry", ... |
3.9.11 20170204 * Fix command I2Cscan * Fix not allowed spaces in Topic, ButtonTopic and SwitchTopic * Make all TELEMETRY, STATUS and COMMAND message topics unique (#4) * Advertise command topic to be used by iobroker (#299) * Fix butten (non)detection if no GPIO_KEY1 is defined (#13) * Change WeMo serialnumber from 7 decimal chars to 8 hexadecimal chars (#18) * Update web page with Build Date/Time, Emulation and mDNS Discovery and Advertise information (#21)
3.9.11 20170204 * Fix command I2Cscan * Fix not allowed spaces in Topic, ButtonTopic and SwitchTopic * Make all TELEMETRY, STATUS and COMMAND message topics unique (#4) * Advertise command topic to be used by iobroker (#299) * Fix butten (non)detection if no GPIO_KEY1 is defined (#13) * Change WeMo serialnumber from 7 decimal chars to 8 hexadecimal chars (#18) * Update web page with Build Date/Time, Emulation and mDNS Discovery and Advertise information (#21)
Version 3.9.11 makes a difference between hourly update and teleperiod information. |
Thanks @arendst! I think this issue can be closed but I can't speak for @evilgreen. |
Thanks to @arendst for listening to his fans ;) |
I came on here to post the same issue, saw that it had been fixed, downloaded the new bin and uploaded over the air! Perfect. FIXED! 👍 |
update interlocking output to include the pair info
3.9.11 20170204 * Fix command I2Cscan * Fix not allowed spaces in Topic, ButtonTopic and SwitchTopic * Make all TELEMETRY, STATUS and COMMAND message topics unique (arendst#4) * Advertise command topic to be used by iobroker (arendst#299) * Fix butten (non)detection if no GPIO_KEY1 is defined (arendst#13) * Change WeMo serialnumber from 7 decimal chars to 8 hexadecimal chars (arendst#18) * Update web page with Build Date/Time, Emulation and mDNS Discovery and Advertise information (arendst#21)
3.9.11 20170204 * Fix command I2Cscan * Fix not allowed spaces in Topic, ButtonTopic and SwitchTopic * Make all TELEMETRY, STATUS and COMMAND message topics unique (arendst#4) * Advertise command topic to be used by iobroker (arendst#299) * Fix butten (non)detection if no GPIO_KEY1 is defined (arendst#13) * Change WeMo serialnumber from 7 decimal chars to 8 hexadecimal chars (arendst#18) * Update web page with Build Date/Time, Emulation and mDNS Discovery and Advertise information (arendst#21)
update interlocking output to include the pair info
TELEMETRY messages sent periodically are used to report various parameters in a single JSON.
Sometime, probably when the new hour of operation begins, TELEMETRY message is sent with only Uptime in the body.
The problem is: I'm using openHAB to extract a single parameter from TELEMETRY message by using jsonpath transformation. When message with Uptime only arrives this generates an error as there is no parameter of interest is present.
tele/sonoff1/TELEMETRY {"Time":"2017-01-29T19:59:17", "Uptime":2, "POWER":"OFF", "Wifi":{"AP":1, "SSID":"crazy", "RSSI":48}}
tele/sonoff1/TELEMETRY {"Time":"2017-01-29T20:02:30", "Uptime":3}
tele/sonoff1/TELEMETRY {"Time":"2017-01-29T20:04:23", "Uptime":3, "POWER":"OFF", "Wifi":{"AP":1, "SSID":"crazy", "RSSI":44}}
May I suggest to either send complete messages all the time or move Uptime to a separate topic?
Thanks!
The text was updated successfully, but these errors were encountered: