Thanks a lot for the feedback!
I checked your other posts and have some notes on the Software part:
I think it's really nice you took this effort, tbh :)
The Evok is planned (well, maybe "wished" is a better word:)) to be rewritten to Python 3 and to a multithreaded application. Along with that, major changes to the API will happen. We will abandon some of the less used APIs (RPC and SOAP probably) and definitely add native MQTT support since it is a driving force in the industry.
How far along is this idea? Would you also be taking PRs? I mainly develop in python3 for my job and have some experience with asyncio (see e.g. https://github.com/mhemeryck/covers), so I might be interested to have a look at that.
The missed state changes of the DI can be detected by checking the state of the DI counter. The counter is implemented in the HW and can count as fast as 10kHz signals.
I wasn't aware of this polling speed!
And a bit of explanation of the low level communication:
The HW boards are connected over SPI
The protocol on the SPI level is modified ModbusRTU
The Unipi kernel module (part of the unipi-kernel-modules package) exposes this communication channe as /dev/unipispi device
The Unipi ModbusTCP server (part of the unipi-modbus-tools) exposes this as a ModbusTCP server running on TCP/502
The rest is correct. Evok polls the ModbusTCP server as fast as it can. And creates a "system image" of the HW state.
I obviously did get some of details wrong, so thanks for pointing this out!
Would you mind if I did include your comments in an edit on this blog post?
I really appreciate this kind of feedback; I never really did ask for your permission to publish on your product in the first place, so I am glad to see your reaction like this.