As much as I like the advantages of a monogamous world, maybe I can offer some advice here. In another Python project I did I found the best way to allow multiple threading-based hardware-interfacing processes to use the same hardware is to make use of the threading.Lock() functionality. I think EmonHub could greatly benefit from it, especially as the number of interfacers grows. In my simplistic world it would actually be rather straightforward to implement.
the treadLock would be added to the init() constructor of the Emonhub class:
threadLock = threading.Lock()
Then the lock just needs to be activated and released in the run() method of the EmonHubInterfacer class, just before and after self.read(), like this:
In this way all interfacers children could do their hardware interaction without any risk of collision with other hardware processes because only one interfacer can acquire the lock at any one time. My excuses if I am overlooking something obvious here and for possibly overstepping any boundaries.
I like this approach and think this is where it should be heading. I dont even need a counter; as long as I only set the interfacer interval hourly it should be just perfect. And yes, I need another NodeID for that, but I could not find anywhere in the config file where the NodeID is linked to an interfacer. Does it have to be hardcoded or how does this work?
I’m afraid I can see no good reason foe multiple interfacers to connect to the same one device via a serial port designed for a single connection.
I have very little input with OEM emonPi version of emonhub so don’t take my position on this as anything more than an opinion, but this is not how emonhub is intended to work.
If an interfacer is intended to interface with a device it needs to accomadate the needs or behaviour of that device. You seem to want to change emonhub and a long established serial protocol rather than simply update the dedicated interfacer to better suit it’s target device. You simply don’t need 2 interfacers for one device.
If one interfacer can handle the requirements, then that surely is the best solution. It was not my intention to infer that there might be two handling the same data stream, only that the stream needed splitting and the two parts with a different timebase handled independently thereafter.
Rs485 and modbus are a different thing, they are designed to co-exist on the same network. I2C and SPI are 2 other types of serial comms that are not intended to be one to one. One thing all these have in common is a master/slave relationship. Plus every device has a unique id (or SS slave select in the case of SPI) which is used in every communication. None of this exists or is needed with the simple serial setup between emonhub and your meter as they are equals and only communicate with each other so no ids needed.
I’m not sure if there is an rs485 modbus interfacer for the OEM emonhub, I have a modbus interfacer that communicates with several modbus devices on the same connection as emonhub is the master and it addresses each device asking for the data it wants, in turn. But this is not something I’ve shared as it is not for the OEM emonhub and it’s a work in progress.
I have also used an I2C interfacer, in fact I think there was one in my experimental branch of emonhub, but that then got removed in the transition the the OEM version.