It was actually Glyn that highlighted it to me,
I just confirmed that the issue lay with the mqtt_input.php and not a Mosquitto or emonHub issue. At the time I was able to recreate the issue at will and documented it all in that same thread. While I was able to get numeric node names working on occasion, the mqtt_input.php behaved quite erratically and this was more so with numeric nodenames.
That may be a vital clue to gain insight to the issue. I did not try restarting (Mosquitto or) the emoncms mqtt_input service, I only tried a reboot after flushing Redis didn’t work. Rebooting has worked every time and I have recommended a reboot many times here on the forum when new inputs do not appear (even those with text names) and in most instances this has worked.
Perhaps we can try just restarting the service rather than rebooting to get us closer to understanding the cause
That is pretty much the crux of it, but if emonhub is able to publish a payload similar to the current http bulk upload api but via MQTT purely for the benefit of emoncms and also publish each and every value in it’s own topic for anything and everything (local?) to be able to use then everyone would be happy.
I’m less concerned about whether it’s JSON formatted (I’m not opposed, I’m just not closed off to options), what is important is the inclusion of timestamps, the (optional?) ability to bulk upload following network outages or server downtime.and a predictable order of input processing so that cross-input processes can be relied upon.
A “bulk over MQTT” approach would also pave the way to a multi-user mqtt solution as an apikey could also be included in the payload.
Another benefit of a “tandem publish” by emonhub is that the “one topic per value” status’s need not be published to the same broker as the “bulk over MQTT” for example if emoncms.org adopts MQTT but users still want MQTT around the house.
[edit] In addition to the above “tandem publish” I would also like to add an emonhub interfacer that uses the current “fetch” api to get the current values of several feeds in one go and publish them on individual topics based on base topic and names defined in emohub.conf, this would make ALL emoncms feeds (incl virtual) available for publishing on the local broker (regardless of emoncms location) without having to use the “Publish to MQTT” process which slows down the input processing (if too many values published) and it would do it without opening and closing the MQTT connection for each value published as the current “Publish to MQTT” does.
To move towards the option of a full MQTT (no http) emoncms we could then look to using similar queries to the http api, expanding the capability of MQTT implemented in emoncms, for example executing the above “fetch” api via MQTT by publishing the query to the “emoncms rx only” topic and the response is published by emoncms to the “emoncms tx only” topic that emonhub is subscribed to so it can publish the individual topics as above.
By making it possible to delegate local stuff including “per value topics” to emonHub and creating a “super highway” between it and emoncms, in a user choice of MQTT or HTTP, users get the best of both worlds, lots of local “status” data readily available on individual topics AND a better emoncms, less loss of data (buffered bulk upload), more accurate data (timestamped data) and faster processing as there is no need for Publish to MQTT’s to be in the input processing. Not to mention a undoubtedly more reliable MQTT experience as emoncms doesn’t need to subscribe to so many topics and/or process each value as a completely separate input that happens to share the same node id as other inputs rather than processing them as a group.
From what I understood the downside is that it makes subscribing to topics and using topics outside of emoncms, e.g by other applications such as nodered and openhab harder as they would then need to decode the json sent from say emonhub.