Today i went to check my emonpi info on the screen and i saw something diferent.
In Power 1 is showing VRMS info
In VRMS, info is 0
Temperature 1 show 0 (should be aprox 17.1)
temperature 2 (curently, i have no sensor, so 0 is ok)
Pulse should show 0 and shows what i think is the power.
But emoncms.org, inputs on the android app and inputs on emoncms local is showing everything good.
Already did a factory reset and still the same.
More details on screenshots
Thanks for reporting, this is indeed a bug. I think I know what could the issue. It might be due to some recent changes to emonhub which may have changed the order of the MQTT data. I will take a look. Should be easy to fix.
Ok, it was as suspected. Issue has now been fixed:
Please run emonPi update (admin > emonPi update) on local Emoncms to pull in the new changes then reboot (admin > Reboot) to apply the changes.
@glyn.hudson or @TrystanLea, can you please elaborate on the cause and the fix for this issue?
I need to understand what is expected of emonhub from the perspective of the emonpi’s lcd software and how flexible that can be, plus what the effects are of data not being as expected.
As well as publishing the data to MQTT in the format
emon/emontx/power1 emonhub also posts the data to MQTT in ‘legacy’ CSV format which is used by the emonPi LCD script in the format
emonhub/rx/[nodeID]/values format e.g.
emonhub/rx/10/x, x, x ,x. As documented on the MQTT technical section of the guide.
This ‘legacy’ format allows the LCD script to just subscribe to a single topic to get all the data from the emonPi. In the refactoring @TrystanLea accidentally changed the order of the CSV values being posted to MQTT in the ‘legacy’ formatt which resulted in the values being displayed on the LCD in the wrong order.
Thanks @glyn.hudson, I understand a bit more now.
Am I right in thinking the “legacy” format was specifically for the now retired Nodes module? So the emonLCD might be the only thing using the “legacy” format now?
@TrystanLea and I have been discussing MQTT in emonHub and currently agree that there should be 2 main implementations, one that publishes local “status” QoS1 “topic per key” data and the other that publishes a “bulk” type input to deliver data to emoncms in a quick, concise and predictable way that uses QoS 2 to confirm reciept before deleting buffered data.
It seems the emonLCD uses neither of those formats. So we need to look at providing a “node per topic” QoS1 solution too, even if only for backwards compatibility. I think this could be a simple switch setting in the “QoS1 mqtt interfacer”, even if 2 instances are needed to replicate current behavior.
[This is mainly a note to myself to refer back to when I start experimenting with the mqtt stuff in emonhub]