# Emonpi display info bug **URL:** \ **Category:** emonPi\ **Tags:** emonpi\ **Created:** [24 February 2018 20:02 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668 "2018-02-24T20:02:50Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![CelsoHenriques](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/celsohenriques/32/9586_2.png) [@CelsoHenriques](https://community.openenergymonitor.org/u/CelsoHenriques)\ **Post date:** [24 February 2018 20:02 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/1 "2018-02-24T20:02:50Z")
Hi all 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](http://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 ![P_20180224_195004](https://community.openenergymonitor.org/uploads/default/original/2X/3/30c429c18912b8f328c3dbb1ccb412d50bec6a33.jpg) ![P_20180224_195023](https://community.openenergymonitor.org/uploads/default/original/2X/d/d26797585c326e8f88035a06e21eb24d0b68088a.jpg) ![P_20180224_195031](https://community.openenergymonitor.org/uploads/default/original/2X/f/f22af9b45e71cbe3e1ce5f2e2f307f6b7bb04914.jpg) ![P_20180224_195015](https://community.openenergymonitor.org/uploads/default/original/2X/8/8265392e13e8bf307d59e680cbbbf0b7a5d839e7.jpg) ![P_20180224_194954](https://community.openenergymonitor.org/uploads/default/original/2X/9/963c241fb99058a4154c39822299182e13d982bc.jpg) ![P_20180224_194946](https://community.openenergymonitor.org/uploads/default/original/2X/d/d591f756d6be9a57b78f5cea796cc5eae483bd46.jpg) Any hints? Best regards, Celso Henriques ---
**Author:** ![glyn.hudson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/glyn.hudson/32/35003_2.png) [@glyn.hudson](https://community.openenergymonitor.org/u/glyn.hudson)\ **Post date:** [26 February 2018 14:35 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/2 "2018-02-26T14:35:38Z")
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. ---
**Author:** ![CelsoHenriques](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/celsohenriques/32/9586_2.png) [@CelsoHenriques](https://community.openenergymonitor.org/u/CelsoHenriques)\ **Post date:** [26 February 2018 16:18 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/3 "2018-02-26T16:18:46Z")
No problem 🙂 Regards, Celso ---
**Author:** ![glyn.hudson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/glyn.hudson/32/35003_2.png) [@glyn.hudson](https://community.openenergymonitor.org/u/glyn.hudson)\ **Post date:** [26 February 2018 16:43 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/4 "2018-02-26T16:43:45Z")
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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [1 March 2018 14:24 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/5 "2018-03-01T14:24:44Z")
@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. ---
**Author:** ![glyn.hudson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/glyn.hudson/32/35003_2.png) [@glyn.hudson](https://community.openenergymonitor.org/u/glyn.hudson)\ **Post date:** [1 March 2018 14:34 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/6 "2018-03-01T14:34:37Z")
As well as publishing the data to MQTT in the format `[basetopic]/[node]/[keyname]` e.g. `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](https://guide.openenergymonitor.org/technical/mqtt/). 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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [1 March 2018 15:00 UTC](https://community.openenergymonitor.org/t/emonpi-display-info-bug/6668/7 "2018-03-01T15:00:13Z")
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]