The 'dev' field describes an object type (similarly to di or relay) so the key has to be constant regardless of the PLC series. You are right, this can be a little bit confusing - it's a piece of history ;-).
Now, we will add the new field of a family containing Patron/Neuron/Axon string.
The 'dev' field fix is a breaking change of the existing API and will be subject to change within an upcoming new Major version.
In the event monitor of FHEM I can see also the following message when I make a "get all": "2022.01.02 14:17:08 3: Neuron (NeuronL513) error decoding response: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 5830 (before "NaN, "circuit": "3_0...") at ./FHEM/00_Neuron.pm line 424." As I can see the error occurs on AI 3_01 or an other till AI 3_04.
The issue was caused by a combination of 64bit Linux kernel and bundled pigpio subsystem (used for peripheral access). After pigpio updating, Evok works on a 64bit platform properly. This change will be part of the next release.
this is not planned, nor it makes sense from the architecture point of view. The SysFS endpoints are generated from the Unipi kernel module, which is aware of the HW it is running on, but not aware of any peripheral devices.
The only way right now is the Evok, or you can directly poll the devices over ModbusRTU. We have some internal discussion from time to time about adding support for extensions to our ModbusTCP service. So far, no work has been done on that part.
please try to download the current version 2.4.10. The issue should be fixed. Please note that watchdog settings (same as other parameters) are stored in RAM memory by default. To burn it into non-volatile memory (FLASH), use the appropriate coil 1003 or call the separate REST request on the same endpoint with parameter nv_save=1.
the Evok doesn't have such logic. If the DI doesn't support counters (which does not on Unipi 1.1), the Evok is not able to share this information. This has to be done in your software.