What is the correct way to support devices which have separate set and separate status group addresses?
Many devices (like popular 16x and 8x switches from Berker) have 2 separate gropu addresses for each switch. You write to one of the addresses to switch on and off, but whenever something happens and switch changes it's value the new value is not written to the bus. Even worse: you cannot READ this address. But instead there is another group address for status. You can read this address to determine if the switch is in on or off state and datagrams are sent by the switch to KNX whenever switch changes state.
I am using <listener> xml tag which can be added to the <object> definition. The placement of this tag is weird. You do not place it in the <object xxx> but as a separate tag.
The problem with <listener> is that
* I have to define the status object anyway. I don't know why it seams that when I don't define it separately linknx is not updating it.
* I am not sure if linknx attempting to initialise main object will attempt to unsuccesfully read the main object of will ask the 'listener' gad instead?
Jeff, can you tell us what was the idea behind 'listener' object? How it works when there are several listeners defined?
My idea would be a bit different. To add status="GAD" parameter to the <object> definition.
The definition would be like this:
Hi, from my perspective, using listener should be fine for your request
I have actors from Busch Jäger / ABB, which also reply the status in a seperate message. (Like the ones used for timers etc.)
Regarding to your question I guess you have to take the following into account for better understanding the behaviour:
The important entity in linknx is an "object". The object has a certain state / value. The object state - or a change in the state - is used to trigger actions (in rules).
An object can have just one main message gad (for writing) - but can have multiple messages for receiving. These are the "listeners". (You suggest to name it "status").
For example, I have also actors, which don't have Status - reply, but "listen" on multiple commands like
"Switch_1stFloor", "Switch_All", "Alarm"…. You can easily add listeners for all these state values and the last received message wins and changes the object. (this is also the typical behaviour of an actor in EIB, if you add multiple messages to the "switch-gad")
Of course you could also write some logic and rules to implement the same - but this is the easiest solution and works easily with knxweb. (because KNXWeb communicates with the "object", not with an "gad".
So for me the current implementation is fine.
Best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that something is missing in linknx to deal with status objects. As Auto-mate already said, adding the status group address as "listener" should work except for the read request at startup.
Perhaps the placement of listener tag seems weird, but since an object can have multiple listeners, I can not use a simple parameter listener="1/2/3" because XML doesn't allow multiple times the same parameter. That's why the listener is a separate tag inside the <object …. > </object> tag.
The principle of being able to use a different address to send read requests than the main address used to send value changes (write or update) is good, but I don't like the parameter name "status" that you propose because "status" doesn't say what the parameter does, but only one possible use case.
What I propose is to add an optional parameter read="true" to the listener tags to tell linknx that this listener address must be used for read requests. The result would look like this:
<object id="lamp1" gad="1/0/2" init="request"><listener gad="2/0/2" read="true"></object>
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I think we are talking about two slightly different things and behaviours.
I would treat 'listener' as something different, and 'status_gad' as something different. Indeed listener is usefull for situations where you would like an object to be changed by multiple other objects (real objects), as you did mention for instance by a '1st floor' and 'all'. This can be usefull for creating artifitial statuses which are calculated in linknx. What I am talking about is something different, a hardware built in 1:1 relationship. Whatever happens, on the bus, for me only the status_gad is important. In Berker switches if someone sends 'all_on', 'all_off' command or whatever else happens, it WILL change the status_gad of this one particular switch anyway. The 'all_on' knx message will always be followed by staus_xxx=on messages for each of the swithches actually toggled by this action.
2) Yes, you could use the 'listener' with the addition of 'read=true' to fulfill this action but it will not be elegant solution for a few reasons:
* it requires to define separate objects for status. At least in my compilation if I did omit the creation of a separate listener object something did not work. I have about 150 completely useless otherwise status objects which show up in KNXWeb and are uneasy to debug. This is against the theory of Jens that there is only one 'object' which you should use in rules etc.
* as Jean François did mention it is not elegant for initialisation
* it IS confusing for new users. I had huge problems to understand how 'listener' really works and I have made large efforts to hack the switches unsuccesfully to report status on the same address, later I have added an extension for KnxWeb to support separate status & write objects (yes, objects) etc before I did try to make it with listeners. They do not suggest the 1:1 relationship.
* it would require to eliminate the need of creating the status objects for the gad included in listener.
Concluding:
* adding read=true & eliminating the need to create separate object for status is a workaround for me, but I don't see it elegant.
Yours
Damago1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The important entity in linknx is an "object". The object has a certain state / value. The object state - or a change in the state - is used to trigger actions (in rules)."
In my situation the object does not have any state. It's state is contained in completely other object. So I have 2 objects: one for writing only for use in actions, and one which has a state that you could use in rules. The clean picture breaks.
2. You could imagine even a different solution: instead of adding status_gad="" to add write_gad="" to make LinKnx write to an other address in an attempt to change object's value, but the actual object value will be left intact till the status_gad will change.
3. The listener also does not address the situation where changing value of an object could be not succesfull. For instance (in my home) I can change value of a main_gate object to 'off' but the gate will not close if something is blocking it. So the gate's status coming from a gate sensor will never arrive, and 'listener' will be useless. In cuffent situation it will lead to a mismatch between object value in LinKnx (gate="off"), and real world object state where gate is actually open ("on").
Yours
Damago1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the correct way to support devices which have separate set and separate status group addresses?
Many devices (like popular 16x and 8x switches from Berker) have 2 separate gropu addresses for each switch. You write to one of the addresses to switch on and off, but whenever something happens and switch changes it's value the new value is not written to the bus. Even worse: you cannot READ this address. But instead there is another group address for status. You can read this address to determine if the switch is in on or off state and datagrams are sent by the switch to KNX whenever switch changes state.
I am using <listener> xml tag which can be added to the <object> definition. The placement of this tag is weird. You do not place it in the <object xxx> but as a separate tag.
The problem with <listener> is that
* I have to define the status object anyway. I don't know why it seams that when I don't define it separately linknx is not updating it.
* I am not sure if linknx attempting to initialise main object will attempt to unsuccesfully read the main object of will ask the 'listener' gad instead?
Jeff, can you tell us what was the idea behind 'listener' object? How it works when there are several listeners defined?
My idea would be a bit different. To add status="GAD" parameter to the <object> definition.
The definition would be like this:
<object id="lamp1" gad="1/0/2" status="2/0/2" init="request">
linknx should always write to GAD and always read from STATUS, and update object based on the STATUS datagrams.
Yours
Damago1
Hi, from my perspective, using listener should be fine for your request
I have actors from Busch Jäger / ABB, which also reply the status in a seperate message. (Like the ones used for timers etc.)
Regarding to your question I guess you have to take the following into account for better understanding the behaviour:
The important entity in linknx is an "object". The object has a certain state / value. The object state - or a change in the state - is used to trigger actions (in rules).
An object can have just one main message gad (for writing) - but can have multiple messages for receiving. These are the "listeners". (You suggest to name it "status").
For example, I have also actors, which don't have Status - reply, but "listen" on multiple commands like
"Switch_1stFloor", "Switch_All", "Alarm"…. You can easily add listeners for all these state values and the last received message wins and changes the object. (this is also the typical behaviour of an actor in EIB, if you add multiple messages to the "switch-gad")
Of course you could also write some logic and rules to implement the same - but this is the easiest solution and works easily with knxweb. (because KNXWeb communicates with the "object", not with an "gad".
So for me the current implementation is fine.
Best Regards, Jens
Hi,
I agree that something is missing in linknx to deal with status objects. As Auto-mate already said, adding the status group address as "listener" should work except for the read request at startup.
Perhaps the placement of listener tag seems weird, but since an object can have multiple listeners, I can not use a simple parameter listener="1/2/3" because XML doesn't allow multiple times the same parameter. That's why the listener is a separate tag inside the <object …. > </object> tag.
The principle of being able to use a different address to send read requests than the main address used to send value changes (write or update) is good, but I don't like the parameter name "status" that you propose because "status" doesn't say what the parameter does, but only one possible use case.
What I propose is to add an optional parameter read="true" to the listener tags to tell linknx that this listener address must be used for read requests. The result would look like this:
<object id="lamp1" gad="1/0/2" init="request"><listener gad="2/0/2" read="true"></object>
Jean-François
1) I think we are talking about two slightly different things and behaviours.
I would treat 'listener' as something different, and 'status_gad' as something different. Indeed listener is usefull for situations where you would like an object to be changed by multiple other objects (real objects), as you did mention for instance by a '1st floor' and 'all'. This can be usefull for creating artifitial statuses which are calculated in linknx. What I am talking about is something different, a hardware built in 1:1 relationship. Whatever happens, on the bus, for me only the status_gad is important. In Berker switches if someone sends 'all_on', 'all_off' command or whatever else happens, it WILL change the status_gad of this one particular switch anyway. The 'all_on' knx message will always be followed by staus_xxx=on messages for each of the swithches actually toggled by this action.
2) Yes, you could use the 'listener' with the addition of 'read=true' to fulfill this action but it will not be elegant solution for a few reasons:
* it requires to define separate objects for status. At least in my compilation if I did omit the creation of a separate listener object something did not work. I have about 150 completely useless otherwise status objects which show up in KNXWeb and are uneasy to debug. This is against the theory of Jens that there is only one 'object' which you should use in rules etc.
* as Jean François did mention it is not elegant for initialisation
* it IS confusing for new users. I had huge problems to understand how 'listener' really works and I have made large efforts to hack the switches unsuccesfully to report status on the same address, later I have added an extension for KnxWeb to support separate status & write objects (yes, objects) etc before I did try to make it with listeners. They do not suggest the 1:1 relationship.
* it would require to eliminate the need of creating the status objects for the gad included in listener.
Concluding:
* adding read=true & eliminating the need to create separate object for status is a workaround for me, but I don't see it elegant.
Yours
Damago1
Two more comments for Jeff's post:
1) Quoting Jens:
"The important entity in linknx is an "object". The object has a certain state / value. The object state - or a change in the state - is used to trigger actions (in rules)."
In my situation the object does not have any state. It's state is contained in completely other object. So I have 2 objects: one for writing only for use in actions, and one which has a state that you could use in rules. The clean picture breaks.
2. You could imagine even a different solution: instead of adding status_gad="" to add write_gad="" to make LinKnx write to an other address in an attempt to change object's value, but the actual object value will be left intact till the status_gad will change.
3. The listener also does not address the situation where changing value of an object could be not succesfull. For instance (in my home) I can change value of a main_gate object to 'off' but the gate will not close if something is blocking it. So the gate's status coming from a gate sensor will never arrive, and 'listener' will be useless. In cuffent situation it will lead to a mismatch between object value in LinKnx (gate="off"), and real world object state where gate is actually open ("on").
Yours
Damago1