You said "timestamp" and I want to make sure I understand.
I make a timestamp upon receipt of the topic (more accurately stated as when I do the database insert). I'm not aware that the Shelly sends a timestamp. What timestamp does MQTT Explorer report?
I use mqtt for many things and I have mosquitto running on a Dell Poweredge server. My network is all gigabit, wired everywhere it is possible. So my tuning == as fast as I can make it. I have multiple access points and the 3em is 25 feet away from the nearest one.
To view the firehose, I am running a very simple python program using the paho client. I subscribe to "#". When a topic arrives, I grab a timestamp and print it. Fast and almost no overhead.
I have never used any of the tools you mention, so I can't report on my experience with them. It is curious that you see different results. How does this affect you?
Okay, I'm glad that we can now agree on the 18.
I don't understand why I see the infrequent 6, without the other 12. Perhaps some time has elapsed between the sets of 18. Would be nice to see inside the mind of the coder.
Since we both seem to be getting all 18, would you also like to get them reported together in one json payload? It might make templating more difficult in HA, but the values at one point in time would be reported together. Perhaps the developer can make this an mqtt option.
Realizing the box may have set on the shelf for a while, the first thing I did from the dashboard was a firmware update.
Current version: 20210720-190729/v1.11.0-g6abd92e
You have latest version on your device!
Is this similar to yours?
Thank you for responding.
I am seeing all 18 topics, even for those that have reported only 0 since I began recording (most zeros are from the CT clamped on the neutral).
I have recorded the information for about three days. All 18 topics appear at the same time, in order, one after another. I am watching the mqtt firehose to visualize this statement.
Though it might be a wrong approach, I am generally getting what I need from my simple python program. I wasn't able to find any documentation, so I developed code based upon my observations of the mqtt firehose. Do you know of any documentation?
There are infrequent reports of just six of the 18 topics, as I mentioned in the original post. I'm working on some code to fix that.
Other advice is welcome.
I have just installed my 3em. It is my first Shelly product. I did update the firmware. I am using mqtt and not the cloud. I am using a custom python program to process the mqtt messages into a mysql database and I view the collection with Grafana.
((about my install -- My 3em is installed on the split single phase 240V 3-wire service (third CT on the neutral) the electrical coop provides. I do not have solar nor batteries. My coop does not yet do time of use metering. They do measure peak load and we pay a charge for the highest demand between the hours of 16:00 and 20:00 that is recorded during the month. I am using the 3em to shed load during that time period during the day.))
I am trying to consolidate the 18 separate mqtt topics and their payloads into a single row in a mysql database.
I am temporarily ignoring topics that contain "energy" as well as the relay until I find a use for them.
These 18 messages represent the value states at a particular point in time (and I want my database row to reflect the states at that point in time). If the mqtt data reporting could be improved, I would like to have these 18 datapoints in a single json payload.
I am currently accepting each topic and holding the payload until I have received all 18 and then I issue a database insert. A second appearance of a particular topic before all 18 have been gathered also triggers the database insert and the start of collection for a new row.
Every so often, the 3em sends only six topics, those for total and total_returned (for each of the three CT). These same topics are also sent in the group of 18. This causes a problem for my program logic that expects all 18. Are these necessary? What is their purpose?
I am unable to find any controls over the frequency of mqtt topic publishing. Is this event driven? Is it possible to make the 3em report more frequently?
I am using the custom mqtt prefix to shorten the topic. The topic up to the /CT number is still quite long. I realize that the topic was probably chosen with all Shelly devices in mind, but I would appreciate a means of shortening it considerably. You can ignore this thought if you find the single json payload acceptable.
Thank you for your time and consideration.
