I have an ABB switch actuator with one output configured with a timer and a push button with two channels.
PB channel 1 sends '1' on, let's say, 1/1/1.
PB channel 2 (long press) sends '0' on, 1/1/1.
Status is sent on 1/1/101 by the actuator.
Here we go :
PB sends '1' on 1/1/1. Actuator switches on the light for 5 minutes. The actuator switch object now has value '1'.
Actuator sends a status of '1' on 1/1/101.
5 minutes later, the actuator will switch off the light automaticaly and send '0' on 1/1/101. The problem here is that the actuator switch object still have a value of '1'!
Then I start Linknx. From the logs, I can see that linknx reads the value on init from 1/1/1. Status of the light is detected has 'on'. Actualy, I'll have to wait a new "switch on then off" to receive a status message and get the value updated correctly.
Default flags for the ABB switch object are CW. So I guess they meant that you should not try to read values from it but rather from the status object.
Now, what can I do?
1) Add the switch object in the status GA 1/1/101 to get it updated. Weird and it could be dangerous too!
2) Configure Linknx so that it reads values on init from the listener gad? Is it possible?
3) ?
Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For my own installation, I've always used the same group address for push-button, actuator and status object. I know that most people use different addresses for status objects, but I still don't see why it would be better. I don't see a situation where it could be useful to have the 2 objects with different values, so conceptually they are one.
It's not possible to make linknx read on the listener gad.
I think that if you configure 1/1/101 as listener in linknx, then add 1/1/1 to the status object of the actuator, it could (I didn't test it) do the job.
Since the write and update flags are not set on the status object, it will ignore the writes on 1/1/1, but since the read flag is set, it will answer to a read on 1/1/1 by a read_response on 1/1/101, wich will set the correct value in linknx because 1/1/101 is configured as listener gad.
Regards,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>but I still don't see why it would be better. I don't see a situation where it could be useful to have the 2 objects with different values
I'll try to give you one. Let's say we only have one GA containing push button switching object, actuator, status leds, etc. The push button sends '1' on this GA. Now, imagine the actuator decides not to close the relay (internal logical function, safety object, even an actuator malfunction, etc...). Status may not be sent because relay state did not change (0 -> 0) and leads to the following situation : PB's, leds, visu, displaying a value of '1'.
I see it as a separation between what it is asked and what it is really given.
>It's not possible to make linknx read on the listener gad.
I guess it is because a linknx object has to be seen has a knx object, ie only one sending flag? From this point of view, it is completely correct. Then, the visu should have two linknx objects associated for a simple lamp : switching object, status object. Switching object with 1/1/1 and 1/1/101 as a listener gad. Status object with 1/1/101.
>it will answer to a read on 1/1/1 by a read_response on 1/1/101
Wow! I never thought that thing should be possible. Reading on a gad triggers answer on another! I have to give it a try.
Jean-Philippe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Wow! I never thought that thing should be possible. Reading on a gad triggers answer on another!
And ... it works!
I am still a bit dubitative as it looks more like a workaround than a real and more consistent approach as could be the dual object visu.
But by now, it does the trick for this particular case.
Thanks!
--
Jean-Philippe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Wow! I never thought that thing should be possible. Reading on a gad >triggers answer on another! I have to give it a try.
>And ... it works!
Yes, I was also very surprised the first time I saw it. I was using the "absence" group address as a second gad on all room temperature controller to force them in frost mode when absent. And when I tried to read this group address, I was really surprised to see all the devices replying to the read request but on a different group address then the one of the request. That's how I discovered it.
>I guess it is because a linknx object has to be seen has a knx object, ie only one sending flag?
Technically speaking, it would be possible, but since no other KNX devices do it, I prefer to stay with the actual implementation to avoid confusing people familiar with this.
>I see it as a separation between what it is asked and what it is really given.
If you consider this separation, then linknx should also have 2 separate objects. And if the main object has the status group address as listener, the fact to read the status object at init will also update the value of the main object.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>If you consider this separation, then linknx should also have 2 separate objects. [...] update the value of the main object.
Ok, the visu displays the value of the status object. Result is consistent.
However, there is still a small glitch.
A PB sends '1' on the main GA and then the actuator don't switch the ouput on (logic, safety, etc).
Then all the other devices listening to this GA are writen with '1'. That includes linknx. The next switch will be a sending value of '0', which does nothing because the ouput is already off. The user will have to click a second time to get a result. Worst, if the output is still disabled, he will have to click twice each time. In other words, he is lost.
My hager PBs handle the situation differently. They have 3 GA's.
-One for sending.
-One for receiving the status of the actuator (or another PB if the actuator has no status feedback).
-One for the led.
In pratice, all the PB listening to the main GA are not affected by a switch order but rather by the status feedback. ie, the switch sending value is based upon the second GA and not itself.
I am maybe a bit of a spoiler tonight but I still haven't decided myself about how to handle it cleanly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would have expected linknx to read from the listener gad a the listener is ment to update the status.
So why not doing the initial read from there, maybe add a init="request" to the listener tag.
I would see this much more logical as to read from the original address that is ment for switching only, not for status updates.
Any chance to get this into the code, maybe a option, not confusing other.
Thanks
denghauser
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Jean-François,
Maybe you could help me with the following issue.
I have an ABB switch actuator with one output configured with a timer and a push button with two channels.
PB channel 1 sends '1' on, let's say, 1/1/1.
PB channel 2 (long press) sends '0' on, 1/1/1.
Status is sent on 1/1/101 by the actuator.
Here we go :
PB sends '1' on 1/1/1. Actuator switches on the light for 5 minutes. The actuator switch object now has value '1'.
Actuator sends a status of '1' on 1/1/101.
5 minutes later, the actuator will switch off the light automaticaly and send '0' on 1/1/101. The problem here is that the actuator switch object still have a value of '1'!
Then I start Linknx. From the logs, I can see that linknx reads the value on init from 1/1/1. Status of the light is detected has 'on'. Actualy, I'll have to wait a new "switch on then off" to receive a status message and get the value updated correctly.
Default flags for the ABB switch object are CW. So I guess they meant that you should not try to read values from it but rather from the status object.
Now, what can I do?
1) Add the switch object in the status GA 1/1/101 to get it updated. Weird and it could be dangerous too!
2) Configure Linknx so that it reads values on init from the listener gad? Is it possible?
3) ?
Thank you!
Hi,
For my own installation, I've always used the same group address for push-button, actuator and status object. I know that most people use different addresses for status objects, but I still don't see why it would be better. I don't see a situation where it could be useful to have the 2 objects with different values, so conceptually they are one.
It's not possible to make linknx read on the listener gad.
I think that if you configure 1/1/101 as listener in linknx, then add 1/1/1 to the status object of the actuator, it could (I didn't test it) do the job.
Since the write and update flags are not set on the status object, it will ignore the writes on 1/1/1, but since the read flag is set, it will answer to a read on 1/1/1 by a read_response on 1/1/101, wich will set the correct value in linknx because 1/1/101 is configured as listener gad.
Regards,
Jean-François
Hello Jean-François,
>but I still don't see why it would be better. I don't see a situation where it could be useful to have the 2 objects with different values
I'll try to give you one. Let's say we only have one GA containing push button switching object, actuator, status leds, etc. The push button sends '1' on this GA. Now, imagine the actuator decides not to close the relay (internal logical function, safety object, even an actuator malfunction, etc...). Status may not be sent because relay state did not change (0 -> 0) and leads to the following situation : PB's, leds, visu, displaying a value of '1'.
I see it as a separation between what it is asked and what it is really given.
>It's not possible to make linknx read on the listener gad.
I guess it is because a linknx object has to be seen has a knx object, ie only one sending flag? From this point of view, it is completely correct. Then, the visu should have two linknx objects associated for a simple lamp : switching object, status object. Switching object with 1/1/1 and 1/1/101 as a listener gad. Status object with 1/1/101.
>it will answer to a read on 1/1/1 by a read_response on 1/1/101
Wow! I never thought that thing should be possible. Reading on a gad triggers answer on another! I have to give it a try.
Jean-Philippe.
>Wow! I never thought that thing should be possible. Reading on a gad triggers answer on another!
And ... it works!
I am still a bit dubitative as it looks more like a workaround than a real and more consistent approach as could be the dual object visu.
But by now, it does the trick for this particular case.
Thanks!
--
Jean-Philippe
>Wow! I never thought that thing should be possible. Reading on a gad >triggers answer on another! I have to give it a try.
>And ... it works!
Yes, I was also very surprised the first time I saw it. I was using the "absence" group address as a second gad on all room temperature controller to force them in frost mode when absent. And when I tried to read this group address, I was really surprised to see all the devices replying to the read request but on a different group address then the one of the request. That's how I discovered it.
>I guess it is because a linknx object has to be seen has a knx object, ie only one sending flag?
Technically speaking, it would be possible, but since no other KNX devices do it, I prefer to stay with the actual implementation to avoid confusing people familiar with this.
>I see it as a separation between what it is asked and what it is really given.
If you consider this separation, then linknx should also have 2 separate objects. And if the main object has the status group address as listener, the fact to read the status object at init will also update the value of the main object.
>If you consider this separation, then linknx should also have 2 separate objects. [...] update the value of the main object.
Ok, the visu displays the value of the status object. Result is consistent.
However, there is still a small glitch.
A PB sends '1' on the main GA and then the actuator don't switch the ouput on (logic, safety, etc).
Then all the other devices listening to this GA are writen with '1'. That includes linknx. The next switch will be a sending value of '0', which does nothing because the ouput is already off. The user will have to click a second time to get a result. Worst, if the output is still disabled, he will have to click twice each time. In other words, he is lost.
My hager PBs handle the situation differently. They have 3 GA's.
-One for sending.
-One for receiving the status of the actuator (or another PB if the actuator has no status feedback).
-One for the led.
In pratice, all the PB listening to the main GA are not affected by a switch order but rather by the status feedback. ie, the switch sending value is based upon the second GA and not itself.
I am maybe a bit of a spoiler tonight but I still haven't decided myself about how to handle it cleanly.
Hi All,
I would have expected linknx to read from the listener gad a the listener is ment to update the status.
So why not doing the initial read from there, maybe add a init="request" to the listener tag.
I would see this much more logical as to read from the original address that is ment for switching only, not for status updates.
Any chance to get this into the code, maybe a option, not confusing other.
Thanks
denghauser