Hi Frank, I did see your post and gave it some thought, but I have very little, if any, input on the “emonpi” variant of emonhub that is included on the emonSD image and since most users tend to opt for the pre-built image there seems little point in maintaining a competing version.
You raise a valid point about device access but I have not yet formed an opinion about the suggested changes.
There is already a threading concern regarding devices in the emonpi variant of emonhub, it’s a loose end that I identified in my “experimental” version and highlighted when the emonpi variant was in development, but development was out of my hands at that time and it took on a different direction.
Currently the settings for all interfacers are all managed by the main thread, so, for example if the jee interfacer is receiving from the serial port and a setting is changed simultaneously there could theoretically be 2 threads trying to access the same serial port at the same time from within emonhub. This I was going to resolve by changing the settings code to queue the writes to the serial port via the interfacer “routing” queues rather than writing directly to the port. However my routing queues were removed in favour of a pubsub library implementation that wasn’t thread safe, that has since been removed but the routing and queing is still not as it was intended. Plus there have been 2 independent PR’s for writing to the jee interfacers serial port (emonpi or rfm2pi) one of which has been merged, neither of which accommodate the settings.
However, I believe your target issue is possibly when the user configures the same interface more than once (correct?) if so I can see the potential issue, but I would have expected this to only be in error (correct?) as I cannot offhand think of why a user would duplicate interfacers unless using multiple devices, eg it is not unheard of to use an rfm2pi and jeelink on the same RPi, they are essentially a GPIO and USB versions of the same device, and this is perfectly acceptable and works well.
How do you propose the lock would work? Would it lock all instances of a certain type of interfacer or lock just the interfacers targeting the exact same device address/id?
Assuming the known threading issue for settings is resolved, is there a real need for the lock? (just questioning out loud, I’m not inferring there isn’t a need) if a user accidentally duplicates a interfacer config exactly, the config will not load due to the need for unique section headers (interfacer names) and if the name was different the setup would probably fail on the second device if the first already has control (eg serial ports), but yes it is better to be safe than sorry, if it doesn’t impact speed or usability too much, ie the point of threading the interfacers is so that no devices were sat waiting for another device to respond and finish before it could then do it’s thing. locking for all/any external device each time any is accessed might cause blocking, where as per device id/address might be complex (maybe not?).
Ideally, I believe that should never happen or be needed, or do you have other thoughts?
IMO, there should be a single interfacer for any one Modbus network bus, to which there can be multiple devices defined and accessed, I’ve no idea if the current Modbus implementation works that way, I have been working on my own Modbus “interfacer” script that does work exactly that way, but it is unlikely to manifest as an emonhub interfacer as I do not use the “emonpi” variant and I no longer develop for the original version, so it is likely to be an independent emonhubesque script that posts to an emonhub socket interfacer for now.
This is at the very least a good point to raise and I will link to it from the emonhub development discussion so that if/when I get back into emonhub dev, it will be easy to find and review at that time.