This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

Multiple listening addresses
#1
A KNX object can be connected to multiple -same type Group addresses. One of them has sending property. In many cases this is essential. How can we achieve the same goal with logic machine? A feedback group address is not always possible. One solution is  to write some short of LUA for each object but this will make the project complicated and unreadable. A direct input of listening only addresses for an object would be very helpful.

Thanks
Reply
#2
Hi
In what case do you need this?
Script only. Use tags to make it simpler.
BR
Reply
#3
I think this post can be helpful for you and it will be the most efficient way.

https://forum.logicmachine.net/showthrea...45#pid2945
Done is better than perfect
Reply
#4
I would do it like that.

Add tag to listening address and then create event script triggered from this tag and use this.

Code:
grp.update('1/1/1', event.getvalue())

Where the 1/1/1 is the group you want to update.  Last sent telegram will be updated to this group.

BR
Reply
#5
Thank you all
All that was the obvious reaction from my side.
It would be easier if there was a straight forward procedure. This would keep the project more readable
Just think of a project with 5000 GAs and a central function switching off everything. I wouldn't even think of such a solution and I wouldn't dare to let all the feedbacks pass through all the line couplers and routers just for the visualization
Developers, please consider this functionality in future firmware releases
Reply
#6
(16.04.2018, 13:55)ncgnick Wrote: Thank you all
All that was the obvious reaction from my side.
It would be easier if there was a straight forward procedure. This would keep the project more readable
Just think of a project with 5000 GAs and a central function switching off everything. I wouldn't even think of such a solution and I wouldn't dare to let all the feedbacks pass through all the line couplers and routers just for the visualization
Developers, please consider this functionality in future firmware releases

In that case you need other way around.
Tag all your local status objects.
Create event based script on your central group and paste this code
Code:
value = event.getvalue()
myobjects = grp.tag('YourTag')
myobjects:update(value)
Change 'YourTag' to your tag.
BR
Reply
#7
(16.04.2018, 15:32)Daniel. Wrote:
(16.04.2018, 13:55)ncgnick Wrote: Thank you all
All that was the obvious reaction from my side.
It would be easier if there was a straight forward procedure. This would keep the project more readable
Just think of a project with 5000 GAs and a central function switching off everything. I wouldn't even think of such a solution and I wouldn't dare to let all the feedbacks pass through all the line couplers and routers just for the visualization
Developers, please consider this functionality in future firmware releases

In that case you need other way around.
Tag all your local status objects.
Create event based script on your central group and paste this code
Code:
value = event.getvalue()
myobjects = grp.tag('YourTag')
myobjects:update(value)
Change 'YourTag' to your tag.
BR
Thanks Daniel
I must admit that this is more efficient than my solution which was close to that but I built the object list manually.
I like efficient code. This solution contributes also the documentation because one can find the general function members easily
Reply
#8
Hi,

If you like efficient code you can do also this (:
Code:
grp.tag('YourTag'):update(event.getvalue())
BR,

Erwin
Reply
#9
(16.04.2018, 20:52)Erwin van der Zwart Wrote: Hi,

If you like efficient code you can do also this (:
Code:
grp.tag('YourTag'):update(event.getvalue())
BR,

Erwin

Thanks, that was my first reaction when I applied Daniel's solution. "Bad" habits inherited from embedded programming I am doing mostly. Smile
Reply


Forum Jump: