Inputs Nodes Value only rssi Error after update of Emoncms version low-write 9.8.28

Emoncms version low-write 9.8.28 Stable was installed, after pressing the EmonBase update button and restarting, the following error has now occurred: Inputs Nodes Value only rssi





after the stop of Mosquitto via : sudo service mosquitto stop

an old Image Backup with Emoncms version low-write 9.8.7 works,
after the update to Emoncms version low-write 9.8.28 Stable the error returns.
about help I would be grateful

Server Information
Emoncms Version low-write 9.8.28 : 2018.01.27
Modules Administration : App v1.0.0 : Backup v1.1.2 : Config v1.0.0 : Dashboard v1.1.1 : EventProcesses : Feed : Graph v1.2.0 : Input : CoreProcess : Schedule : Time : User : Visualisation : wifi
Buffer loading…
Writer Daemon is running with sleep 60s
Server OS Linux 4.9.35-v7+
Host emonpi emonpi (127.0.1.1)
Date 2018-02-28 21:57:12 CET
Uptime 21:57:13 up 1:01, 1 user, load average: 0.02, 0.03, 0.05
HTTP Server Apache/2.4.10 (Raspbian) HTTP/1.1 CGI/1.1 80
MySQL Version 5.5.59-0+deb8u1
Host localhost (127.0.0.1)
Date 2018-02-28 21:57:12 (UTC 01:00‌​)
Stats Uptime: 3712 Threads: 3 Questions: 2318 Slow queries: 0 Opens: 77 Flush tables: 1 Open tables: 70 Queries per second avg: 0.624
Redis Version 2.8.17
Host localhost:6379 (127.0.0.1)
Size 249 keys (515.41K)
Uptime 0 days
MQTT Version 1.4.14
Host localhost:1883 (127.0.0.1)
Pi CPU Temp 48.31°C
Release emonSD-07Nov16
File-system Set root file-system temporarily to read-write, (default read-only)
Memory RAM Used: 27.92% Total: 970.93 MB Used: 271.09 MB Free: 699.84 MB
Disk Mount Stats
/ Used: 50.58% Total: 4.86 GB Used: 2.46 GB Free: 2.17 GB
/boot Used: 36.32% Total: 59.95 MB Used: 21.77 MB Free: 38.17 MB
/home/pi/data Used: 2.90% Total: 22.95 GB Used: 681.93 MB Free: 21.1 GB
PHP Version 5.6.33-0+deb8u1 (Zend Version 2.6.0)
Modules apache2handler : bcmath : bz2 : calendar : Core v5.6.33-0+deb8u1 : ctype : curl : date v5.6.33-0+deb8u1 : dba : dio v0.0.4RC4 : dom v20031129 : ereg : exif v1.4 : fileinfo v1.0.5 : filter v0.11.0 : ftp : gettext : hash v1.0 : iconv : json v1.3.6 : libxml : mbstring : mcrypt : mhash : mosquitto v0.3.0 : mysql v1.0 : mysqli v0.1 : openssl : pcre : PDO v1.0.4dev : pdo_mysql v1.0.2 : Phar v2.0.2 : posix : readline v5.6.33-0+deb8u1 : redis v2.2.7 : Reflection : session : shmop : SimpleXML v0.1 : soap : sockets : SPL v0.2 : standard v5.6.33-0+deb8u1 : sysvmsg : sysvsem : sysvshm : tokenizer v0.1 : wddx : xml : xmlreader v0.1 : xmlwriter v0.1 : Zend OPcache v7.0.6-devFE : zip v1.12.5 : zlib v2.0 :

Client Information
HTTP Browser Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Screen Resolution 1920 x 1080
Window Size 1903 x 937

Oh dear, there’s a couple of issues I can see in addition to the obvious problem of the Mosquitto service failing.

For some reason all the mqtt data is being published at a per key topic level but all the power and voltage data is being published to the rssi topic. This is why you are not seeing any other input data in emoncms and most likely the reason you are seeing inputs with numeric keys created by the per node level mqtt. I’m not sure these should both be used in parallel if they are both being processed in emoncms.

I wonder if this is linked to either the recent EmonHub emon-pi variant interim update or even the more recent changes to the mqtt implementation to fix the Emonpi display info bug - #4 by glyn.hudson. When exactly did you last do an emonPi/emonSD update?

Additionally I can see there are transmissions being sent out via the RFM2Pi, there is not enough log to see what they are, but I can see a couple of “ack” confirmations, is your system configured to send data out over the RFM network? eg emonGLCD (not that those packets use ack’s). More log would be useful, please attach or copy in-lne the text rather than pictures of text.

@TrystanLea can you assist?

Thanks @Luiflm2 @pb66 looks like I’ve missed another bug, where names for a node are not defined. In the process of fixing now.

Apologies @Luiflm2, I missed the issue you highlighted there with the rssi advancing across several inputs. I’ve implemented a fix which is now available via emonpi update.

@pb66Paul, the last update I did on Monday evening, after that the error was immediately there.

@TrystanLea, after the update today the error has been fixed.
but now a new error has been added, under Node-Red the EMONCMS flows are no longer working.

O dear! could you include an emonhub.log? I cant quite see whats going wrong, Im not that familiar with node red, @glyn.hudson can you see the issue?

Does the update on an EmonPi update node-red as well? I’m wondering if it has picked up the new EmonCMS Node that I did.

Could you open up the emoncms node and screenshot that please.

Yes, I think that would be a good move, none of the above addresses the “confirmed sent packet size: → ack” entries in the log snippets either.

I think that partially depends on which button you use, the “update emonpi” button will install/update node-red-node-emoncms via npn, where as the “update rfm69pi” button won’t. (see Update EmonPi Button or Update EmonBase Button? - #15 by pb66). So as I expect the “update emonpi” to have been used, I now wonder why a change would be pulled in on the last update when the previous update was only on Monday. Has the node-red stuff changed again since then?

No, it was just a thought as this looks like a NR error not an emonhub issue or is that a predefined EmonPi flow?

No idea. I just copied the name over from the “emonpi only” part of the emonpi update script

https://github.com/openenergymonitor/emonpi/blob/master/emonpiupdate#L56

1 Like

In node-red, can you check your Palette Manager and tell me what version of the emoncms node you have installed;

Hamburger top right > Manage Palette > Palette > search for emoncms

It should tell you v0.1.0 if not select update to 0.1.0

Paul

sorry for my late answer, node-red-node-emoncms was actually updated from version 0.0.15 to 0.1.0, it behaves differently.
grafik
Data Type must be changed if necessary
all errors have been fixed.
Thanks for your fast help, you are great!

@Luiflm2 - I’m still intrigued by the “confirmed sent packet size: → ack” entries in the log snippets. Can you please confirm if these still exist and/or if they were expected, ie do you knowingly have data transmitted over RFM from the emonPi/emonBase?

@pb66 Paul, some used sensors are replicas of nathan chantrell TinyTX3, they ask as far as I can remember if the data package arrived. RFM69Pi V3 on my EmonBase confirms the received package.
Have these sensors been running for over 4,5 years now.

Ahh ok! that makes sense. So they are just confirmations that the ack’s to received packets have been sent by the RFM. The message text could do with some editing in that case. The current log message is derived from seeing the “send” confirmations being in the format of “4b” to tell us a frame of 4 bytes was sent so “confirmed sent packet size: → 4b” made sense, apparently less so for an ack confirmation.

[this is another note to self, i can revise the messages if I know the full range of utilization]

In theory, it should, by default, work the same but offer different functionality. Can you tell me what it defaulted to and what you needed to do to make it work please?

The Emoncms node is preset to Data Type Legacy Processing, it didn’t fit on every flow, I had overlooked the fact that it was a new version.
grafik
after I had the hint from you the settings could be done with little effort.
I can only repeat, you guys are really great.

1 Like

Interesting, in theory, the ‘Legacy Processing’ should behave exactly as before! Still as you say, easily fixed.