+- Logic Machine Forum (https://forum.logicmachine.net)
+-- Forum: LogicMachine eco-system (https://forum.logicmachine.net/forumdisplay.php?fid=1)
+--- Forum: Hardware (https://forum.logicmachine.net/forumdisplay.php?fid=12)
+--- Thread: Not reliable inputs (/showthread.php?tid=2773)
Not reliable inputs - buuuudzik - 03.08.2020
A 2 years ago I've found that there is a lack of possibility for updating input value when GA has different value than input (changed by other source or telegram failed because of traffic peak).
This is bad but not terrible because it is possibility to read from db what is current state of input (not from knx bus) and send it cyclically to the bus. I am doing this for very important inputs especially for pool heating.
But unfortunately today I've found worst case that probably inputs are event-based. For me input can update its state with some innertion because of CPU usage. But EVERY input should have to update properly its internal state. It is totally unnacceptable that device shows bad state of its internal input. But today I've found that there is a possibility that LM5 can do such thing.
I had no-voltage contact from pool heater controller which close when there is a demand for heating and it switches LM input state. And LM sends telegram to switch KNX output in actuator.
And today I've found that LM had internal bad input state for 3 days and it doeasn't update it in this time. So I've tested if input would change state when I will toggle it so firstly I've disconnected cable from real contact, and nothing changed because contact where opened but on LM it was closed. So then I've simmulated its closing on LM, nothing changed but when I've then again open input then finally it updates properly its internal state and also sends telegram to the bus.
I am not sure what is the direct reason and please tell me how input should work in such edge cases:
- when backup is loaded? Does input get state from backup and not change its value in db untiil some event happen (change input state electronically),
- what happens when input state GA is send by another device? Is it not writable or writable and the value in db will change? (It is easy to check but I cannot do it today)
Another question: is there a possibility to check very low level what is true binary input state? I mean lower level than:
"SELECT name, address, updatetime, value FROM lm5ex_rio"
I very like LM but this part of it has very bad implementation. Reliability of I/O state inside device is foundations of stable system. Of course KNX TP adding some uncertainty but this is understandable but I/O inside device?
The device in which such situation occured has firmware 20180828 and it is LM5 with multiple IOs.
RE: Not reliable inputs - admin - 04.08.2020
Some of the reactor devices (LM5 Reactor IO V2 and GM) already have binary input status mode which behaves exactly as you want. This can be added to Reactor IO v1 but this will take a bit of time.
RE: Not reliable inputs - buuuudzik - 04.08.2020
But for now maybe do you have some little program for direct reading from input like e.g. on PLC or event in Arduino).
How can I send request to LM for read current state (really measure input state) and return this value?
I could do this cyclically e.g. every 5 min to monitor and exceptionally correct.
So could you tell me how it now works? Inputs are checked and updated only on event? What about case with backup?
RE: Not reliable inputs - admin - 04.08.2020
There's no easy way of reading input state directly. Newer FW for you device has an additional value send on start-up for binary input mode. If you restore the backup using standard procedure then the value will be updated after reboot. If you manipulate db directly there's no way for all other processes to know that the stored value changed until a reboot happens or object value is updated via bus/write/update.
RE: Not reliable inputs - buuuudzik - 04.08.2020
(04.08.2020, 15:09)admin Wrote: There's no easy way of reading input state directly. Newer FW for you device has an additional value send on start-up for binary input mode. If you restore the backup using standard procedure then the value will be updated after reboot. If you manipulate db directly there's no way for all other processes to know that the stored value changed until a reboot happens or object value is updated via bus/write/update.
I'm not manipulating db directly. I am only reading from db current state, but I see that it can be different than current input state.
Quote:Newer FW for you device has an additional value send on start-up for binary input mode. If you restore the backup using standard procedure then the value will be updated after reboot.
This is probably still not a solution, because I've used normal backup procedure. And additional value send at start-up is not enought, it should have possibility to add cyclically refresh value or interface(preffered) for user which can decide and customize solution to specific case especially when LM controls e.g. whole HVAC system.
Really do you not have any package or some c/c++ code or low level task which can be executed from lua also by exec command?