Hi,
this is a question to the open discussion board…and I would like to know, if somebody has a hint for me or even better, Jean Francois, whether if this is an idea you could find useful to be implemented in linknx one day.
My Problem: I have a bunch of different types of dimmers, blind- / awning actors.
Some of them, especially the MDRCs support a status objects. I.e. after changing the value incrementally (up, down), they send an object with the current value on the bus. (since I didn’t know this before and had to google this on the web: MDRC= Modular DIN rail component or “zu deutsch: Reiheneinbaugerät für die Hutschiene :-)
But I have others (like Busch Jäger Powernet, Surface mounted devices),which don’t provide such status-objects.
I.e. KNXWEB just shows the last “command”. I.e. if the last message was “down” – the blind is shown as “closed”, even if 3 seconds later a “stop”-command was issued and the blinds are just closed by, for example, 10%. That’s my problem.
How could I make the visualization being displayed in the same detail for all devices, also for the ones without the “status” feedback? I.e. show the % of closed blinds or dimmed lights?
My humble opinion would be simple: by implementing a similar approach as for the logic in the devices:
The status-object in these devices seem to be implemented by just using a timer.
I.e. one has to define the duration for 100% opening / closing the blinds and programm the value for comparison in the device. The device then just calculates, how long an up-/down command was executed and gives back the %-value at the end of the cycle.
I.e. if I want to practically develop such code to work "externally" on the (eib)bus as a "software device" I would need to implement the following:
- a persistent internal status value ( percentage or integer) in the device.
- a persistent timer for an up-cycle / (or separate down if different???)
- a bus-monitor to capture following commands:
- up commands
- down commands
- stop commands
- set commands.
---and maybe “locking commands”…like a storm-watch….but this is for version 2.0 :-)
The logic would be as follows: (let’s start somewhere in the middle and assume, that 100% means “closed”)
1) If an up/ down command is captured, then the timer starts. (incremented/ decremented)
2) if the timer is bigger than the max. defined value, then the status is set to 100% in case of a previous “down” command(or 0% for an “up” command)
…afterwards the status-object is send on the bus.
3) if a “stop” command is captured and the timers is still running, the timer is stopped and an %-value is calculated and send as the status on the bus.
4) if a “set” command is captured, the status-object is just set to this same value and mirrored on the bus.
(this can be more complex – but it could be a start)
In linknx there is already the monitoring of the bus and sending of values implemented. XML interface to define such devices and messages/objects is also already there. Timers are implemented in a certain way.
I guess the majority of change would affect the timers to support – lets say a realtime-counting of ~1 second granularity.
All the other things could be handled via the existing functionality.
What do you think – Is there anybody, who would also like to have such functionality for visualization?
…@Jean-Francois, maybe I can convince you to implement such code extension in linknx.?? :-)
If yes: I would be happy to support by providing samples of xml-definition or suggestions and more detailed use case descriptions …and do testing…but regrettably I cannot write the C-code :-(
Thanks anyhow for sharing your opinions with me,
Best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think such solution within linknx would be quite complicated and not very reliable. I have the same problem with all kinds of devices which are in an undefined state for a while (for instance you send pulse to open the gate, and between this moment and circa 30 seconds later the gate should be open.
From my experience such solutions you propose is quite unreliable (anything can happen to the gate inbetween - snow, cat, manual intervention, malefunction itp. and the internal persisten value is than desynchronized with device state.
If you would like to implement it anyway I would propose to use:
* either some more complicated conditions using timer-cycle condition type (with treshold and reset-time). see the 'action syntax' part of the wiki with a new experimental tags for this purpose
* or use LUA scripts which will give you much freedom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
this is a question to the open discussion board…and I would like to know, if somebody has a hint for me or even better, Jean Francois, whether if this is an idea you could find useful to be implemented in linknx one day.
My Problem: I have a bunch of different types of dimmers, blind- / awning actors.
Some of them, especially the MDRCs support a status objects. I.e. after changing the value incrementally (up, down), they send an object with the current value on the bus. (since I didn’t know this before and had to google this on the web: MDRC= Modular DIN rail component or “zu deutsch: Reiheneinbaugerät für die Hutschiene :-)
But I have others (like Busch Jäger Powernet, Surface mounted devices),which don’t provide such status-objects.
I.e. KNXWEB just shows the last “command”. I.e. if the last message was “down” – the blind is shown as “closed”, even if 3 seconds later a “stop”-command was issued and the blinds are just closed by, for example, 10%. That’s my problem.
How could I make the visualization being displayed in the same detail for all devices, also for the ones without the “status” feedback? I.e. show the % of closed blinds or dimmed lights?
My humble opinion would be simple: by implementing a similar approach as for the logic in the devices:
The status-object in these devices seem to be implemented by just using a timer.
I.e. one has to define the duration for 100% opening / closing the blinds and programm the value for comparison in the device. The device then just calculates, how long an up-/down command was executed and gives back the %-value at the end of the cycle.
I.e. if I want to practically develop such code to work "externally" on the (eib)bus as a "software device" I would need to implement the following:
- a persistent internal status value ( percentage or integer) in the device.
- a persistent timer for an up-cycle / (or separate down if different???)
- a bus-monitor to capture following commands:
- up commands
- down commands
- stop commands
- set commands.
---and maybe “locking commands”…like a storm-watch….but this is for version 2.0 :-)
The logic would be as follows: (let’s start somewhere in the middle and assume, that 100% means “closed”)
1) If an up/ down command is captured, then the timer starts. (incremented/ decremented)
2) if the timer is bigger than the max. defined value, then the status is set to 100% in case of a previous “down” command(or 0% for an “up” command)
…afterwards the status-object is send on the bus.
3) if a “stop” command is captured and the timers is still running, the timer is stopped and an %-value is calculated and send as the status on the bus.
4) if a “set” command is captured, the status-object is just set to this same value and mirrored on the bus.
(this can be more complex – but it could be a start)
In linknx there is already the monitoring of the bus and sending of values implemented. XML interface to define such devices and messages/objects is also already there. Timers are implemented in a certain way.
I guess the majority of change would affect the timers to support – lets say a realtime-counting of ~1 second granularity.
All the other things could be handled via the existing functionality.
What do you think – Is there anybody, who would also like to have such functionality for visualization?
…@Jean-Francois, maybe I can convince you to implement such code extension in linknx.?? :-)
If yes: I would be happy to support by providing samples of xml-definition or suggestions and more detailed use case descriptions …and do testing…but regrettably I cannot write the C-code :-(
Thanks anyhow for sharing your opinions with me,
Best Regards, Jens
I think such solution within linknx would be quite complicated and not very reliable. I have the same problem with all kinds of devices which are in an undefined state for a while (for instance you send pulse to open the gate, and between this moment and circa 30 seconds later the gate should be open.
From my experience such solutions you propose is quite unreliable (anything can happen to the gate inbetween - snow, cat, manual intervention, malefunction itp. and the internal persisten value is than desynchronized with device state.
If you would like to implement it anyway I would propose to use:
* either some more complicated conditions using timer-cycle condition type (with treshold and reset-time). see the 'action syntax' part of the wiki with a new experimental tags for this purpose
* or use LUA scripts which will give you much freedom