Openhab 2.5.M1 with PLCLogo Binding 2.5.0.201902182038
Several pulse things are configured with default observer and pulse=600, e.g.
Thing pulse logo_licht_gang_ein [ block="VB10.0", pulse=600 ]
Thing pulse logo_licht_gang_aus [ block="VB20.0", pulse=600 ]
Each VB is mapped to one NI of the Logo.
For each pulse thing there is one Switch item that uses the channel to send commands. The UI is configured in a way that only "ON" can be sent as command.
Expected Behavior
If a command is send to a pulse thing, the corresponding NI of the Logo receives a 1 state for the configured pulse time (600ms) and then always reset to 0.
Current Behavior
If several commands are received on a channel during a short time (multiple clicking in the UI), the NI sometimes gets stuck at 1 state. So no more commands can be sent.
Possible Solution
Somewhere there is a race...
I don't know if the problem comes from handling to many commands or if a new command is received just after a state change of the readback (e.g. after 600ms).
For testing, I changed the UI to toggle between ON and OFF commands. So if the command is still ON (during the 600ms), an OFF command is sent. This triggers the problem more often.
(OTOH it allows to "reset" the problem, because it also works on a channel that is already "stuck" at ON).
A simple solution could be a simplified version of the pulse thing: Don't read back from observer and just sent a pulse of configured length. Default to "0->1->0" pulse but allow by configuration to have a "1->0->1" pulse thing.
Steps to Reproduce (for Bugs)
Send severeal commands during a short time period.
Context
Quite large installation with 11 Lights that each have a ON and an OFF command. User interface with habpanel. Several users including kids and young people, so the system MUST be robust against "stressful" behaviour.
Your Environment
Openhab 2.5.M1 with PLCLogo Binding 2.5.0.201902182038
Several pulse things are configured with default observer and pulse=600, e.g.
Thing pulse logo_licht_gang_ein [ block="VB10.0", pulse=600 ]Thing pulse logo_licht_gang_aus [ block="VB20.0", pulse=600 ]Each VB is mapped to one NI of the Logo.
For each pulse thing there is one Switch item that uses the channel to send commands. The UI is configured in a way that only "ON" can be sent as command.
Expected Behavior
If a command is send to a pulse thing, the corresponding NI of the Logo receives a 1 state for the configured pulse time (600ms) and then always reset to 0.
Current Behavior
If several commands are received on a channel during a short time (multiple clicking in the UI), the NI sometimes gets stuck at 1 state. So no more commands can be sent.
Possible Solution
Somewhere there is a race...
I don't know if the problem comes from handling to many commands or if a new command is received just after a state change of the readback (e.g. after 600ms).
For testing, I changed the UI to toggle between ON and OFF commands. So if the command is still ON (during the 600ms), an OFF command is sent. This triggers the problem more often.
(OTOH it allows to "reset" the problem, because it also works on a channel that is already "stuck" at ON).
A simple solution could be a simplified version of the pulse thing: Don't read back from observer and just sent a pulse of configured length. Default to "0->1->0" pulse but allow by configuration to have a "1->0->1" pulse thing.
Steps to Reproduce (for Bugs)
Send severeal commands during a short time period.
Context
Quite large installation with 11 Lights that each have a ON and an OFF command. User interface with habpanel. Several users including kids and young people, so the system MUST be robust against "stressful" behaviour.
Your Environment