Wow! That’s interesting and puts a different perspective on things!
Just ran some tests to try this out and found as far as emonHub and Mosquitto are concerned numbers are fine, but any topics with numeric node names or numeric index’s (input names) are ignored by the emoncms MQTT input api.
I currently have an emonPi running the very latest emonSD on the bench, it is also posting to emoncms.org.
I tested this by commenting out the “nodename” line for the emonpi entry in emonhub.conf, without a nodename I could see the data published to emon/5/power1 etc (and the data is posting ok to emoncms.org as node 5) but it is not seen at the local emoncms.
i can however subscribe to the topic from the command line
pi@emonpi(ro):~$ mosquitto_sub -v -u 'emonpi' -P 'emonpimqtt2016' -t 'emon/5/#'
emon/5/power1 0
emon/5/power2 0
emon/5/power1pluspower2 0
emon/5/vrms 0
emon/5/t1 0
emon/5/t2 0
emon/5/t3 0
emon/5/t4 0
emon/5/t5 0
emon/5/t6 0
emon/5/pulsecount 0
emon/5/rssi 0
so this would confirm the MQTT is ok, it’s just not being accepted by emoncms.
I tested this further by commenting out the input names ("names = ") line in the conf
pi@emonpi(ro):~$ mosquitto_sub -v -u 'emonpi' -P 'emonpimqtt2016' -t 'emon/5/#'
emon/5/3 0
emon/5/4 0
emon/5/5 0
emon/5/6 0
emon/5/7 0
emon/5/8 0
emon/5/9 0
emon/5/10 0
emon/5/11 0
emon/5/rssi 0
emon/5/1 0
emon/5/2 0
again it works fine in emonhub and mosquitto, I then tried setting a nodename = 5 which made no noticeable change at either emoncms instance nor mosquitto.
I then returned the nodenames line to “emonpi” expecting the local emoncms to start updating with a second set of “emonpi” inputs named “1” through to “11” but it didn’t, again all ok in mosquitto.
pi@emonpi(ro):~$ mosquitto_sub -v -u 'emonpi' -P 'emonpimqtt2016' -t 'emon/emonpi/#'
emon/emonpi/1 0
emon/emonpi/2 0
emon/emonpi/3 0
emon/emonpi/4 0
emon/emonpi/5 0
emon/emonpi/6 0
emon/emonpi/7 0
emon/emonpi/8 0
emon/emonpi/9 0
emon/emonpi/10 0
emon/emonpi/11 0
emon/emonpi/rssi 0
This confirms the emoncms MQTT input api will not accept numeric node names or input names, or so I thought !!!
With the emonhub.conf back to original, I tried swapping out “power2” to just “2” to test if an explicit numerically named topic would work.
pi@emonpi(ro):~$ mosquitto_sub -v -u 'emonpi' -P 'emonpimqtt2016' -t 'emon/emonpi/#'
emon/emonpi/power1 0
emon/emonpi/2 0
emon/emonpi/power1pluspower2 0
emon/emonpi/vrms 0
emon/emonpi/t1 0
emon/emonpi/t2 0
emon/emonpi/t3 0
emon/emonpi/t4 0
emon/emonpi/t5 0
emon/emonpi/t6 0
emon/emonpi/pulsecount 0
emon/emonpi/rssi 0
I was quite surprised to see an input named “2” was created in the local emoncms (and power2 stopped updating), wondering how that happened I returned that input name back to “power2” in emonhub.conf and edited “power1” to just “1” and was even more surprised to see the previously created input “2” replaced by an input “1” in emoncms, however I do not know if it was the same inputid renamed or it was deleted and replaced with a new inputid.
But as I was confused by how a single “numeric” topic is handled differently to a batch of numerically named topics posted individually, so I tried commenting out the “names =” line again in emonhub.conf and what happened then really threw me. the input “1” (previously input “2”) changed to input “11”, which had not been previously tested individually using a numeric name!!!
<img src=“/uploads/default/original/2X/0/0652b7049b065596a7544b475a4f55cc4ffb1444.png” width="690"height=“270”>
I suspect this last revelation in particular is very much linked to both the “duplicated inputs at reboot” and the “unable to save processlist” issues rather than the MQTT input API’s reluctance to accept numeric node and input names though.
I hope this info will help in debugging the issues mentioned and perhaps the way the emoncms MQTT input API handles node and input names should be improved to accommodate numeric names too?
Sorry for the long post I sort of wrote it as I was doing further tests and had no idea of the full results when I started 