Triggering of rules does not work

Help
lobomz
2010-11-15
2012-12-14
  • lobomz
    lobomz
    2010-11-15

    I am trying to do a very simple thing … I want to activate scenes with a 1bit address on a certain group address.

    So, everytime I send a "1" or "0" (no matter which one), I want linknx to send an 8bit value (e.g. "0") to a group address activating the scene (GA 1/3/3).

    I thought, this to be a very simple task, but most surprisingly, I am misled :)

    So here is my linknx object definition:

         <object type="1.001" id="1_7_50_LZ_Raumpanel_0" gad="1/7/50" flags="cwtuf" init="off" >(1/7/50)LZ_Raumpanel_0</object>
          <object type="5.xxx" id="1_3_3_LZRaumpanel" gad="1/3/3" flags="ctuf" init="persist">(1/3/3)LZRaumpanel</object>
    

    And these are the corresponding rules:

        <rule id="Aufruf_LZ_Raumpanel_01">
          <condition type="object" id="1_7_50_LZ_Raumpanel_0" value="on" trigger="true">
          </condition>
          <actionlist type="if-true">
            <action type="set-value" id="1_3_3_LZRaumpanel" value="0" />
          </actionlist>
        </rule>
        <rule id="Aufruf_LZ_Raumpanel_00">
          <condition type="object" id="1_7_50_LZ_Raumpanel_0" value="off" trigger="true">
          </condition>
          <actionlist type="if-true">
            <action type="set-value" id="1_3_3_LZRaumpanel" value="0" />
          </actionlist>
        </rule>
    

    Basically, this works (as long as I use the actionlist type="if-true"), but not every time. Please have a look onto the Busmonitor:

    #   Zeit        Service Flags   Prio    Quelladr    Quelle          Zieladr Ziel    Rout    DPT Typ Daten   
    1   22:12:36.630    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    2   22:12:36.631    vom Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    3   22:12:36.660    vom Bus     L   0.0.0   Keine gültige Quelladresse. 1/3/3   frei    7   1 Byte  Write   $00 | 0 %   
    4   22:12:38.077    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    5   22:12:39.199    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    6   22:12:40.138    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    7   22:12:41.113    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    8   22:12:42.422    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    9   22:12:43.696    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    10  22:12:45.207    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   -   Read        
    11  22:12:45.208    vom Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   -   Read        
    12  22:12:46.732    zum Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    13  22:12:46.733    vom Bus     L   0.0.0   Keine gültige Quelladresse. 1/7/50  LZ_Raumpanel_0  6   1 bit   Write   $01 
    14  22:12:46.770    vom Bus     L   0.0.0   Keine gültige Quelladresse. 1/3/3   frei    7   1 Byte  Write   $00 | 0 %
    

    So the rule is only working if there is any other bus traffic in between, it does not work if I send the same value onto 1/7/50 frequently.

    I am very impressed about linknx, so I still hope that there is a solution for this problem. Perhaps any one can help me, please.

    Best regards,

    Stefan

     
  • Ben
    Ben
    2010-11-16

    Hi,

    There is a difference between "on-true" and "if-true" .
    I think in your case you would prefer using "on-true" condition that means "when the value changes".
    "on true" means "each time the value is true (or false), this is not a trigger condition.

    Regards,

    Ben

     
  • lobomz
    lobomz
    2010-11-16

    Hi Ben,

    thank you for your reply … I thought if-true is the same as on-true, it is just renamend in linknx 0.0.1.27

    Nevertheless, according to you answer, I would need "if-true" as I want the rule to send a telegram everytime if a value on the bus is sent.

    Anyway, of cause, I'll try "on-true" and let you know what happens … :)

    By the way, where do you get the information from -- do you read (or write) the code  - or is there any documentation?

    Cheers,

    Stefan

     
  • JensH
    JensH
    2010-11-16

    Hi
    Jeff, have you planned to release a 0.0.1.28 shortly?
    (to officially release the time-counter -condition and the fixes in the TimerTasks, the new interface to the XML server t read the timers etc..)
    I can offer to add some changes in the documentation….(for example the "s"-flag is also worth to be mentioned…and I could add some sample for the time-counter…)

    At least for me the current  CVS is now quite stable…
    Where do you think we could add some "best practices" in the wiki?  In parallel to the "interesting tools"? If you prepare the section I can add something there.

    @Stefan, you use 0.0.1.27, right?
    I just wonder, why your (ETS?) trace just shows

    ...vom Bus L 0.0.0 Keine gültige Quelladresse. 1/7/50 LZ_Raumpanel_0    6  1 bit Write $01
    

    only once before linknx correctly fires the action…
    Could you possibly check with vbusmonitor, whether linknx (or better eibd) receives all message from the bus correctly or whether this is already filtered in the BCU?

    just an indea…
    Best Regards, Jens

     
  • lobomz
    lobomz
    2010-11-16

    Thanks folks for your help!

    OK - I tried to use "on-true" and as expected - this didn't work at all ;(

    Yes I am using 0.0.1.27 -- and I read Jeffs' Post (I got a hint to it at knx-user-forum.de). Jens - I am sorry, but I don't know if I have vbusmonitor (didn't bother up to now) -- but I checked by starting linknx as a process (not as a deamon), so I could read the messages. What I can see in fact is that linknx doesn's seem to react at all to my values I sent rapidly onto the bus. It seems as if the system "thinks" these new requests are the same - so it just neclects them (don't know if I expressed this clearly). This makes me think that linknx doesn't get the values sent.

    I am using a Weinzierl KNX-Router (750 -- labled from Eibmarkt) on a dockstar with debian lenny for this. Any hints how I should proceed to get all the bus traffic into linknx?

    Best regards and thanks,

    Stefan

     
  • JensH
    JensH
    2010-11-17

    Hi Stefan,
    The question I would like to clarify first is:
    a) Is linknx not getting the message from the bus or is it
    b) not responding correctly?

    For me it seems, that inknx is not getting the message from the bus…

    For example, if I start linknx here (as a deamon) and in the configuration xml is have configured:

    <config>
    <logging output="/opt/linknx/log/service.log" format="%d %5p > %c %x - %m%n" level="INFO"/>
    ...
    

    I get the following service.log from linknx, when I press a (light-)button frequently:

    2010-11-17 01:14:46,356  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:50,024  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:50,440  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:51,394  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:52,261  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:52,752  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:53,632  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:54,578  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:55,018  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:55,913  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:56,406  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:56,804  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:57,702  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:58,112  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    2010-11-17 01:14:58,526  INFO > Object  - New value off for object EG_WoZi_LichtHaupt_Schalten (type: 1.001)
    

    …You see,  I get the "OFF" as often as I want. That gives me the evidence, that linknx receives the message from the bus correctly.

    My "linknx" is connected to eibd (see bcusdk) and the eibd is fetching the EIB messages from/to the bus via an usb interface.
    I'm not sure, because I don't have an IP router - but also for routers linknx is not directly talking to the router, right?
    I thought also for IP routers: linknx is talking first to eibd and eibd is then talking to the (Weinzierl) Router, right?

    So if you have installed eibd from bcusdk), then you should also have some commandline tools installed automatically from the bcusdk.
    Please try to call: (on the machine running eibd)

    vbusmonitor1 local:/tmp/eib
    

    …and wait, whether you see messages from the bus…

    in another terminal window running in parallel you could try to send messages:

    groupswrite local:/tmp/eib "1/7/50" 1
    

    This should show up in the "Vbusmonitor1" running and - if configured - create a log entry.
    If you call this "groupswrite" 10 times - it should create 10 entries. If not - then there is the problem with the connection to the EIB bus. (and the issue is probably not within linknx)

    (by the way: on my ubuntu the "groupswrite", "vbusmonitor" etc. are installed under /usr/local/bin)

    Again: Sorry, if I have little experience, running ETS monitors.  I thought this causes problems…so please check first with vbusmonitor1 instead of ETS.
    Just an idea,
    best Regards, Jens

     
  • Ben
    Ben
    2010-11-17

    Hi,

    Maybe you can use flags="cwtus" instead of flags="cwtuf".
    And check your ETS flags (be sure using only R flag with each group address).

    Regards,
    Ben

     
  • lobomz
    lobomz
    2010-11-17

    Wow - this is really a lot reply in a short time -- thanks, folks.

    So Ben, again, I thought the "s" flag is the old implementation of "f". I will check tonight (must go to work …). And there is only linknx sending to the group addresses 1/7/50 and 1/3/3. These are only test addresses, so no interference with other devices.

    Jens, as I am using a dockstar (Arm processor - comparable with pogo plug), I used a cross-compiled package - for eibd and linknx. I didn't know that the command was "vbusmonitor1". I checked that I have the command and with your advice, I will test tonight. I know about the logfile but as I rapidly trigger values on the bus, I thought it is more convenient to see the answers directly in a terminal window - this is the reason why I started linknx directly.

    My eibd is running on the same machine, and of cause, linknx is talking to eibd (not to the router which I use solely as an interface in tunnelling protocol - so no confusion about IGMP). What happens when I send something with ETS3, it sends the command vi IP to eibd running on the dockstar (so no direct communication with the bus it all goes via eibd).

    I'll write again tonight :)

    Cheers,

    Stefan

     
  • JensH
    JensH
    2010-11-17

    Hi Stefan
    I guess the change in the flags from "f" to "s" will not bring any benefit.
    The "f" (="force") was used to send commands to the bus without checking its previous state. Afterwards the "s" (=stateless) was introduced to have this behaviour sldo for incomming commands (and to make the if-true sctions working). But in 0.0.1.27 the "f" and "s" are the same - in the code they both map to "stateless" - you can use the one or the other…makes no difference.

    What do you mean, when you say, you rapidly trigger commands on the bus?
    1) how do you trigger commands? (by groupswrite? ETS?)
    2) what means rapidly? 2 per second, 5 per second?
    3) what happens, if you send just one "1/7/50" every second? (which is quite slow in my opinion)

    I had eibd and linknx running on an old PPP-based buffalo linkstation. Since a year, only the eibd runs on that linkstation (in the cellar) and the linknx has moved to a tiny virtual machine on a small ubuntu server together with some other daemons (fhem…etc)
    I had never any performance problems - but I had some issue with eibd and the usb interface. For me the logic you describe above in your definition file looks well - that's why I'd assume the issue might be related to eibd.
    by the way: Do you use caching on the eibd?
    I think we will know more, when you can verify with vbusmonitor(1),whether the commands are really going to the bus correctly.

    best Regards, Jens

     
  • lobomz
    lobomz
    2010-11-17

    Dear Jens,

    I usually send test telegrams by ETS3 in the busmonitor onto the IP Address of the eibd device. "Rapid" means something like 1 or 2 shots per second (this shouldn't be a traffic issue for the bus). When I send a "1" onto 1/7/50 every second is what I showed in the first post: Nothing happens - so no reaction from Linknx (probably due to eibd not responding). Only if there is any other bus traffic in between (like a read command or the values from the weather station), I get a reaction from linknx.

    I happen to be unable to start vbusmonitor1 - it gives the following reply:

    debian:/tmp/eib# busmonitor1 local:/tmp/eib
    Open failed: Connection refused
    

    I checked my startup - xml and it only contains "logging level="INFO"/", so it is another place and another time format, but I couldn't find my telegrams there, because for testing purposes, I didn't start linknx as a deamon and then is seams that it prints out the messages onto the screen rather than into the logifle.

    I will do some other tests tomorrow - perhaps you have an idea why i cannot start vbusmonitor1?

    Regards,

    Stefan

     
  • lobomz
    lobomz
    2010-11-17

    Ehm - what do you mean by caching with eibd? My starting parameters are:

    eibd -D -T -S -d -i ipt:192.168.1.9
    
     
  • JensH
    JensH
    2010-11-18

    Dear Stefan,
    don't give up, we will try to sort this out. It's worth it! :-)
    I'd suggest to go step by step to see what is working and what not.
    1) switch off ETS - disconnect and don't use any monitoring with ETS (maybe that's over the top - but if we bring it to work, you can test later with ETS…
    2) check eibd and the tools
    the documentation is here
    http://www.auto.tuwien.ac.at/~mkoegler/eib/sdkdoc-0.0.4.pdf
    See pages 157 onwards….
    maybe you can switch on logging in eibd (like this)

    eibd -d/var/log/eibd.log -u -t4 -e -i  ipt:192.168.1.9 -TRDS
    

    in the documentation you can see the explanation for the parameters. (I'm not sure about the -e, because I have an USB backend - but you can test.)
    eibd then creates a logfile under /var/log/eibd.log - you can trace with a tail -f (if availabe on you device / busysbox?)
    -t4 sets the log-level
    the -u is not needed, but this is used, if you want to uses the tools with a local socket i.e. "local:/tmp/eib"…
    i.e. use

    vbusmonitor1 local:/tmp/eib
    

    if you don't enable the -u, the adressing has to go to:

    vbusmonitor1 ip:127.0.0.1
    

    The "cache" is described on page 160. But since you don't start eibd with -c, it shouldn't be active.
    if you start

    eibd --help
    

    , it shows the supported backends / frontends, which were included during compilation.
    If the help-output is missing for the "-c …", then it is probably not compiled into your eibd. (which is good for troubleshooting now)

    3) start the vbusmonitor1 as described above
    the documentation (pdf) states on page 161, that busmonitoring is not working anymore with the tunneling enabled: "Enabling this server prohibits the normal bus monitor mode (vBusmonitor is still working)."
    therefore "busmonitor1" is not working use v(!)busmonitor1 instead.

    vbusmonitor1 ip:127.0.0.1
    

    4) try to send message via the commandline: (send a message to your bus to another device and see, whether it works:
    (you find the documentation of the command-line tools on page 162 onwards.)
    to send an EIS1 "on" run
    groupswrite ip:127.0.0.1 "x/y/z" 1
    (I use the local:/tmp/eib instead the ip:127.0.0.1 - but this should be the same)
    watch the result in the vbusmonitor1 - output or in parallel in the /var/log/eibd.log…
    5) do the same for the "1/7/50"…
    play around with the other tools if you want…
    tell me the result… :-)

    …if linknx is not logging, then this might be a reason of missing compilation of log4cpp… but this we can check later…
    best Regards, Jens

    PS: regarding the other tools: is use the  (undocumented) "mrestart" commandline to reboot an ancient BJE Solo once a week,because otherwise after some weeks the LEDs are not working anymore… and my wife complains. I could buy another / newer BCU, but this workaround is cheaper :-)

     
  • jef2000
    jef2000
    2010-11-18

    Hi,

    When you start eibd with -i parameter, you have to use "ip:127.0.0.1" instead of "local:/tmp/eib". E.g.:
    vbusmonitor1 ip:127.0.0.1

    The same applies for all eibd commands (groupswrite, groupread, …..)

    What do you see in linknx log messages when you send 1 multiple times at address 1/7/50. Do you see a log message for every command sent (as suggested by auto-mate)?

    If some commands doesn't reach linknx, tou can also start eibd without -d option and with -t65535 option to see all eibd log messages.

    Regards,

    Jean-François

     
  • lobomz
    lobomz
    2010-11-18

    Hi,

    thank you both for replies.

    Jens, when I wrote my latest post, I already had the doc oben - but the iformation is a little bit spread accross some pages - so thank you for your advice.

    As well, I always forget to put the "ip:" before the address (I had the same topic before … sorry).

    Jens, linknx is logging - that is not the problem - only when I don't start linknx as a deamon, it prints out the logging directly into the terminal window - and only in this case, the log is not written into the file (which is IMHO ok). I didn't check with tail (which is in fact a good idea and I didn't know the -f switch …)

    Jean-Francois, If I send multiple times at 1/7/50, only the first telegram will be recognized. With the rest, I don't get anything from linknx (which I saw already by the output when starting linknx as a program, not a deamon).

    I am more and more convinced that the problem is the eibd itself. Perhaps it is either the compiled version on my dockstar, or it is the 0.0.4 version of eibd (according to a user in knx-user-forum, I should rather use a version from the git), or could be a problem of the weinzierl IP router.

    So I will go in detail through your advices when I am at home (and my wife allows me to - she was understandingly already a bit upset yesterday ….). I'll let you know.

    Thank you once again - especially because it is probably not a directly linknx related problem.

    Cheers,

    Stefan

     
  • lobomz
    lobomz
    2010-11-18

    OK Folks,

    I will try to answer step by step (could be several posts depending on how far I get tonight ;) )

    First - just a short statement to the documentation of eibd. I've read the interesting passages (at least tried to), but for me it is not much help as it only states what switches are possible. It doesn explain how they are used and what they are needed for… So I easily get stuck and the more I appreciate your help.

    I cannot start eibd as recommended via:

    eibd -d/var/log/knx/eibd.log -u -t4 -e -i  ipt:192.168.1.9 -TRDS
    

    - the logfile tells me:

    Layer 2(0006E6D8,4CE59C57) Open
    Layer 2(0006E6D8,4CE59C57) Opened
    initialisation of the eibd unix protocol failed
    

    It doesn't matter if the default path for -u (/tmp/eib) is existing or not - eibd just doesn't start with "-u"
    Even by ommiting this parameter, eibd won't start (as seen in the last lines of eibd.log):

    Layer 2(0006E6D8,4CE59DF7) Recv L_Data low from 1.1.9 to 0/0/2 hops: 01 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE59DF8) Recv L_Data low from 1.1.9 to 0/0/2 hops: 00 T_DATA_XXX_REQ A_GroupVLayer 2(0006E6D8,4CE59E81) Open
    initialisation of the backend failed
    

    It doesn't accept the "-e" switch thus asking for an URL …
    I get problems with repeated traffic when adding the "-R" switch.

    And I cannot start the eibd as a deamon from the bash, but when I start it as:

    eibd -t4 -i -u ipt:192.168.1.9 -DTS
    

    It shows the output directly into the terminal window (as it should).
    When I now send onto address 1/7/50 (no matter if it was from ETS3 or groupswrite, this is always recognised by eibd:

    Layer 2(0006E6D8,4CE5AB40) Recv L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB42) Send L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB42) Recv L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB43) Send L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB43) Recv L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB44) Send L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB44) Recv L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB45) Send L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB45) Recv L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB49) Send L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    Layer 2(0006E6D8,4CE5AB49) Recv L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    

    The same now with vbusmonitor1 -- sending:

    debian:~# groupswrite ip:127.0.0.1 1/7/50 0
    Send request
    

    will give:

    LPDU: BC 00 00 0F 32 F1 00 80 0F :L_Data low from 0.0.0 to 1/7/50 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
    LPDU: BC 00 00 0B 03 F2 00 80 00 39 :L_Data low from 0.0.0 to 1/3/3 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write 00
    

    Here comes the funny thing for tonight:
    As long as I have vbusmonitor1 running, linknx gets the telegrams and answers with the rule. If I turn off vbusmonitor1, linknx doesn't reply any more.

    … I could use -c command (it is compiled in my code)

    Regards,

    Stefan

     
  • lobomz
    lobomz
    2010-11-19

    I tested the switch -c and it doesn't make any difference.

    So as an intermediate conclusion, the rule is triggered correctly (every time - no matter if another telegram is in between or not) if vbusmonitor1 is running. As I don't have any workaround for this, I will try to install another package (from the wiregate repo) - and see if this will make a change.

    Stefan

     
  • JensH
    JensH
    2010-11-19

    Hi Stefan,
    sorry, I was quite busy….
    To test the -u and daemon issue you could try to run eibd as root. But this is not your main problem and you can follow up on this later.

    To get the main issue sorted out, I'd suggest you write a mail to: bcusdk-list@lists.sourceforge.net and describe the problem.
    Just write your binary version and the setup of devices and tell them the strange behaviour with / without vbusmonitor.

    Martin & Co. will probably know a solution quickly - at least they can better help you.

    Best Regards, Jens

     
  • lobomz
    lobomz
    2010-11-20

    Hi Jens,

    no need for excuses - your answers come very quickly keeping me pretty busy ;)

    Now I solved the problem! The rules are working every time I trigger them!!!!!

    I used the Makki's repositories which he kindly linked in http://knx-user-forum.de/sonstiges-verwaltung-archiv/11132-extrem-guenstiger-linux-pc-gefunden-3.html. He used the actual version from the git and told that there are a couple of fixed issues.

    Thank you so much - now it ist too late for me, but I'll start to build up my rules the next days and I am looking forward for this.

    Best regards,

    Stefan