Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init="request" for object of type "20.102" does not trigger a read group address on the bus at startup #60

Closed
knxste opened this issue Jan 21, 2021 · 4 comments

Comments

@knxste
Copy link

knxste commented Jan 21, 2021

I have the following object declaration:


when I start linknx, it writes a read request on the bus for the first object, but not for the second. If I manually place a read request on the bus using knxtool groupread, the object gets updated correctly by the read response.
I'm using linknx 1.38 with knxd. I look into what linknx writes using knxtool groupsocketlisten.
If somebody can givme a hint on where to look, I can work out a fix to propose.
Thanks
Ste

@knxste
Copy link
Author

knxste commented Jan 21, 2021

for some reason the form did not keep the pasted object declaration. Let me try again:
''
''
apologies for that

@knxste
Copy link
Author

knxste commented Jan 21, 2021

nope. I attach the declaration excerpt here.
20.102_issue.txt

@2franix
Copy link
Member

2franix commented Jan 22, 2021

Hi,

A few leads to follow:

  • AFAIK, when init="request", the initialization takes place upon the first read request for that object. Can you force linknx to get the value for this object to see if it triggers the expected request on the bus? Does the return value correspond to the expected one?
  • Can you set logging to the debug level and send its content to maybe get more hints as to what is going on?
  • there is a 1 second timeout on read requests. If the device did not answer within that time, the object is set to its type's default value.

Thanks!

PS: to insert your configuration excerpt, make sure to enclose it with triple backticks like so:

    ```
    <object id="on_off_sala" type="1.001" init="request" gad="2/3/4" flags="cwu"/>
    <object id="modo_bagno_P1" type="20.102" init="request" gad="2/6/11" flags="cwu"/>
    ```

It forces markdown to interpret the text as plain text, so that it is not confused by XML content. The output would be like this:

<object id="on_off_sala" type="1.001" init="request" gad="2/3/4" flags="cwu"/>
<object id="modo_bagno_P1" type="20.102" init="request" gad="2/6/11" flags="cwu"/>

@knxste
Copy link
Author

knxste commented Jan 22, 2021

Many thanks, Cyrille, for your quick answer and your hints. You helped me to understand how initialization works and to solve the issue.
The following code works just fine:

<?xml version="1.0"?>
<config>
    <objects>
        <object id="on_off_sala" type="1.001" init="request" gad="2/3/4" flags="cwu"/>
        <object id="modo_bagno_P1" type="20.102" init="request" gad="2/6/11" flags="cwu"/>
    </objects>
    <rules>
        <rule id="test_on_off_sala" init="eval">
            <condition type="object" id="on_off_sala" value="on" op="lte" trigger="true"/>
            <actionlist>
            </actionlist>
        </rule>

        <rule id="test_modo_bagno_P1" init="eval">
            <condition type="object" id="modo_bagno_P1" value="frost" op="lte" trigger="true"/>
            <actionlist>
            </actionlist>
        </rule>
    </rules>
    <services>
        <knxconnection url="ip:localhost:6720"/>
        <xmlserver type="inet" port="1028"/>
    </services>
</config>

To explain a bit, I have several rules that I use to trigger on update of an object, the condition does not have a "value" clause, just the "trigger" clause. This does not cause linknx to send a read on the bus, while the code above does. I therefore replaced the missing "value" clause with a clause which is always true to obtain the behavior I want.
Thanks again
Ste

@knxste knxste closed this as completed Jan 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants