Dear all.
Im facing a problem regarding the Fan configuratios and command as per attached PDF file.
Can you please help me ?
On the bOS log:
Users : 14/04/2025 17:44:01 : User : SetValue : Object: Devices\KNX\Ground floor\ISE + FA + H2O\AEF-1-GF RUN, Name: Value, Value: False
But the on the KNX is not present
Thanks
Please see the pdf attached
Grazie Ricardo.
I already create 2 object:
0/0/21 >>> AEF-1-GF RUN
0/0/32 >>> AEF-1-GF RUN STATUS
In the ETS:
But is the same...
So accordingly to your actuactor on ETS, I can see that you have:
0/0/21 ONOFF command
0/0/32 ONOFF status
And that's perfectly fine.
But you created two objects on bOS, when you just need one.
Delete the AEF-1-GF Status object;
Keep the AEF-1-GF RUN object;
On this object change accordingly to the example below:
In the tab Values, change the template to Power for example.
Add the object to your visualization.
And test again :) Don't forget to check in the visualization if the object is set to "Control Type: ToggleButton"
The status and the ETS its change only if i set the Communication-Transfer "False"
But the device on site is not comutate
I guess that you may have messed something around when importing the ETS addresses, and you also messed with the parameters.
Lets try this:
Change Value Type to 1.001 Switch instead of 1.002 Bool
Change Transfer to True
Change Read to False
This is the way a 1 Bit object looks like when you create an empty one, this is the way to go. There's not need to change the parameters like you did on your example.
Also, on the Values tab (on top), change the template to lets say "Device".
Test it out again.
Best regards
Hello,
Well, the problems you described previously had nothing to do with bus speed. You had incorrectly defined read/write addresses, or missing read addresses, and some stuff messed up or misconfigured on bOS.
Furthermore, KNX TP allows for up to 50 telegrams per second under ideal conditions, which is a pretty high telegram rate. So if your bus is "talking too much" something may be wrong on your installation and you need to double check that. You can check that by analysing the Group Monitor on ETS and see how the telegrams behave, like if several telegrams are repeated or end up lost, etc.
I have some "complex" installations, with several bus couplers, and never had to mess around with write telegrams per second. But if that worked for you, perfect, problem solved.
Best regards
Hello,
This happens because you're using a single address to send ON/OFF, and expect the same address to be used as status. It doesn't work properly that way on a normal situation. But there are some exceptions (there are some systems that don't have separated addresses).
It doesn't matter that you set the Read as true on bOS, if the Read flag on ETS is not set to true. You're sending a command, but not getting a status feedback in return. What you see on Group Monitor, is the address being written, that is not supposed to be the status of the ON/OFF output, this is just a reminder that the command you're sending was written on the device. You have to use a separated status feedback object.
The best way is for you to create an object for ON/OFF command, and other for STATUS address. This is how it should be.
Example:
0/0/21 >>> AEF-1-GF RUN
0/0/22 >>> AEF-1-GF RUN STATUS
So unless you're using some system that doesn't have a separated status feedback object, you should get two different objects, and add them to Address and Status Address (set the On Connect to Read Status Address).
Best regards