Bear in mind this was just a PoC introducing bidirectional comms and data routing, it was never completed as I couldn’t raise any interest from OEM to test and discuss MQTT structure, it was then left to stagnate until the imminent launch of the emonpi hardware when Trystan asked for MQTT and bidirectional comms to be added to emonhub (v1.2). when I revised my request for testing and opinion on this v2 he took this code, rapidly changed it and the emonpi variant was born, I’ve not bothered going back to it since. But despite being unpolished or even unfinished it remains closer to the intended function of emonhub and it hasn’t been through the cycle of being changed and then partially changed back that the emonpi variant has so it is easier for me to continue from where I left off than learn, fix and possibly revert the emonpi variant.
The subject of logs keeps coming up and even changing the way the settings are checked. emonhub is platform agnostic (or at least it was) I run emonhub on windows too, we cannot build in any dependence on any linux only services eg journald etc. The logs have been a long standing blessing to the OEM project, they have resolved issues with emoncms, emonTx’s, emonTH’s, MQTT, serial, rfm to mention just a few, rather than cull the messages we should be expanding on them, the loglevels are there to reduce/increase logging output. For example the suggestion of removing the “Sent to channel(start)” and “Sent to channel(end)” messages is the right thing to do, but it should be understood the reason they are there is because of the vast amount of code added with no error or status logging meant when we had the “thread is dead” issues there was no info to work with to resolve the issue, as soon as I added those messages it was obvious what the issue was, it just took so long for the code to then be fixed that those messages had become essential to debugging and they remained beyond the fixes to help confirm the fix. Yes they can come out now, but had the code been written with adequate logging they would never have been added and the issue would of been resolved years sooner, perhaps before it was released? So the trend must be to make emonhub logging more verbose not less. There are other points too, but TBH I see little value in debating them. I have no control over what happens to emonpi variant of emonhub, that’s the one widely used, I understand that version is more appealing as it has more features than v1.2 but it arguably has less than my v2 and left under my control where would emonhub have been now after 5 more years of development?
[edit - Just to say it’s not all bad! There is a lot of good stuff gone into the emonpi variant too, like the additional interfacers for modbus etc. There is much stuff I would want to try and carry over from the emonpi variant but the more it diverges the bigger the task becomes and more backwards compatability is needed, regardless of whether it’s the right approach or not eg the mqtt!]