Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


Tick, Tock, Do you get pauses on your HC2 scene clock?


robmac

Recommended Posts

I could have given this topic a few names. What you see is not what you get would be another.

 

So the scenario

I have a couple of scenes

  1. A turn everything I want "off at night" off.
  2. A version of my turn on my morning alarm scene with a load of extra devices

The code for both at the end

 

They have been around for a long time and I use these to check my network is functioning after an upgrade. What I call my "stress test". The name is not because it is a stress test in the true sense of the phrase but more to do with how I feel after an upgrade and these scenes result in a zwave lockup when run.

 

Now for the questions.

 

Does anyone else see random pauses in their network when firing a lot of commands at it?

 

Now the other questions that are a bit more complex. It is the what you see is not what you get part.

 

 

When I get these delays, sometimes lights etc that claim to be switched off/on as the value has changed in HC2 are still burning bright or still dark.

 

Anyone know how HC2 can have a message saying that a device has changed state but the physical device has not changed?

 

I think Fibaro(possibly all) devices send a response on acceptance of the command before the device has executed the command. 

 

Is this correct?

 

Each of these devices when  switched individually react instantly almost all of the time. 

 

On

Please login or register to see this code.

Off

Please login or register to see this code.

 

The scenes.

 

Please login or register to see this code.

Please login or register to see this code.

 

Link to comment
Share on other sites

I can relate to that.

 

I asked myself, long ago, what is the safest way to control a device? Then I saw some posts regarting the "dead" status of a device, and how to get out of that.

They detection of failure is the 'log' property, something you don't see often used on the forum!

This script works best if you have a mains operated device that you can power on and off.

 

I wanted to use that script in production, but I never did. At the moment, I can live with the off failure

 

Maybe one thing: if you do

 

fibaro:call(device.deviceid, 'turnOff')

 

That command will be placed in the Z-Wave queue, even if you know the device is already "off". So I think you can reduce the number of commands, by checking if the command is really needed.

 

Please login or register to see this code.

 

Edited by petergebruers
Link to comment
Share on other sites

Just now, Jamie mccrostie said:

@robmac Yes often same devices show  latency on "all off" every time.

Infact one dimmer sw2 which is prob the closest to HC than any others always last to pop off by four seconds

Link to comment
Share on other sites

28 minutes ago, Jamie mccrostie said:

Infact one dimmer sw2 which is prob the closest to HC than any others always last to pop off by four seconds

It *might* be the device before that one, in the queue, that's causing it. I say *might* because it's difficult to test and we get no peek at the queue, so it's a stab in the dark (pun intended).

Link to comment
Share on other sites

30 minutes ago, Jamie mccrostie said:

Infact one dimmer sw2 which is prob the closest to HC than any others always last to pop off by four seconds

If you find the time, I'd be really interested what my script in post #3 does on that device (or any other suspect).

Link to comment
Share on other sites

  • Topic Author
  • Hi Peter,

     

    Checking for value before sending is my normal pattern but at the time I wrote my code my HC2 was failing a lot. The values in HC2 did not always reflect the true state of the device as I do not poll my devices. I was getting the situation where the system would crash and after I recovered would have the wrong state in the HC2 for some devices that had been switched with their switches while HC2 was dead. The scenes would therefore not control them so I removed the "if value not the value I want"  check that used to be in the scenes. Also it is good way to force a stress test:mrgreen: of the upgrade so I can decide if I have issues but when I trust my HC2 fully I will remove again.

     

    I think there is a lot in what you say about the z-wave queue. I am sure it is this that gets clogged up with inbound and outbound messages.

     

    One thing on your code. I am not sure if your HC2 is not polling your devices  

    Please login or register to see this code.

     really works. I have not tested this theory. Do you think it does? I guess if you kept getting transfer fail in this code then the device would  still get marked as dead and the option would kick in. 

     

     

     

     

     

     

     

    Link to comment
    Share on other sites

    1 hour ago, robmac said:

    Hi Peter,

     

    Checking for value before sending is my normal pattern but at the time I wrote my code my HC2 was failing a lot. The values in HC2 did not always reflect the true state of the device as I do not poll my devices. I was getting the situation where the system would crash and after I recovered would have the wrong state in the HC2 for some devices that had been switched with their switches while HC2 was dead. The scenes would therefore not control them so I removed the "if value not the value I want"  check that used to be in the scenes. Also it is good way to force a stress test:mrgreen: of the upgrade so I can decide if I have issues but when I trust my HC2 fully I will remove again.

     

    I think there is a lot in what you say about the z-wave queue. I am sure it is this that gets clogged up with inbound and outbound messages.

     

    One thing on your code. I am not sure if your HC2 is not polling your devices  

    Please login or register to see this code.

     really works. I have not tested this theory. Do you think it does? I guess if you kept getting transfer fail in this code then the device would  still get marked as dead and the option would kick in. 

     

     

     

     

     

     

     

     

    Hi @robmac

     

    I also have seen this especially when I set my good night and it switches off all the lights downstairs, outside, etc.

    They also don't switch off in the same order each time.

     

    At the moment I just fire the 'off' everywhere without checking status beforehand. I often wondered if one as efficient as the other

    Strategy 1: One command to turn everything off  (whether it needs it of not)

    Strategy 2: One command to check status (assuming it needs to check with device)  and a possible second one to turn off

     

    for these gross/far reaching scenes I was thinking about running a check afterwards just to see if all was now showing off (contracts my point earlier but hey no one is perfect)

    I have had the odd occasion on where a light is still on in the morning (much to my wife;s annoyance) but they are few and far between

     

    I have noticed the that phone or tablet interface shows on when it is really but I just put that down top latency or bug in those interfaces (probably the latter) 

     

     

     

     

     

    Link to comment
    Share on other sites

    1 hour ago, robmac said:

    (...)

    One thing on your code. I am not sure if your HC2 is not polling your devices  

    Please login or register to see this code.

     really works. I have not tested this theory. Do you think it does? I guess if you kept getting transfer fail in this code then the device would  still get marked as dead and the option would kick in. 

     

     

    I can't really sum it up. I've toyed a lot with that script, and all I can say... it's complicated! 

     

    Here's the output of my script, when I unplug a device BEFORE it is marked dead:

     

    Please login or register to see this code.

    I think the key point is... The status is "busy" for a while, then "transfer failed", then "dead". If you wake up a dead device, it goes through these stadia again, so the script ends after a preset time to avoid looping forever.

     

    This is the output of a DEAD device, that I plugged in right before I ran the script (and nothing else is controlling the device):

     

    Please login or register to see this code.

    So it recovers from the "dead" state" but it takes a while.

     

    And this is what happens, when the device is ALIVE, but right before you run the script, you remove power. Then, after about 5 seconds, you plug it in. I think this simulates a "device does not respond for whatever reason" scenario.

     

    Please login or register to see this code.

     

    It's a kind of "safe send" script.

    Link to comment
    Share on other sites

  • Topic Author
  • Hi @petergebruers ,

     

    You gave me an idea with you code. So I did a bit more testing. From my testing the value and log are almost always updated within a tick.

     

    I also discovered that using the log value has a risk. If you have two devices on a Switch2 2* then each gets the Transfer_was_OK so you may get a false report that is not to do with your current command but is part of the command to a prior device if it is on the same node.

     

    I think this might impact you code if the table of devices has this special case. My devices and network are generally healthy so I am not getting any fails other than on a couple of battery devices but still get the delays.

     

    Please login or register to see this code.

     

    Thinking about this it could be a bit of a bug. Should HC2 put that log to all devices on the node?

     

     

     

     

     

    Edited by robmac
    Link to comment
    Share on other sites

  • Topic Author
  • 34 minutes ago, AutoFrank said:

    Strategy 2: One command to check status (assuming it needs to check with device)  and a possible second one to turn off

     

    I am fairly sure that HC2 does not check the physical device but assumes that the value it has is correct. I

    Link to comment
    Share on other sites

    5 minutes ago, robmac said:

    Hi @petergebruers ,

     

    You gave me an idea with you code. So I did a bit more testing. From my testing the value and log are almost always updated within a tick.

     

    I also discovered that using the log value has a risk. If you have two devices on a Switch2 2* then each gets the Transfer_was_OK so you may get a false report that is not to do with your current command but is part of the command to a prior device if it is on the same node.

     

    I think this might impact you code if the table of devices has this special case. My devices and network are generally healthy so I am not getting any fails other than on a couple of battery devices but still get the delays. (...)

     

     

    Thanks for reporting back. Indeed, if you look at the web interface, you'll notice the "log" updates on al slaves of a master device. The script I posted runs only one device ID at a time (so worst case it takes 45 seconds to move on to the next ID), so it is possible to test, for instance, a double relay. In fact, that is what I'm testing right now.

     

    Are you saying, at the moment, you get almost no delays in your code, but still some devices are slow to respond?

     

    Link to comment
    Share on other sites

    4 minutes ago, robmac said:

     

    I am fairly sure that HC2 does not check the physical device but assumes that the value it has is correct. I

     

    Indeed. A getValue does not request anything from the device.  The assumption as that either the HC knows the state (because it's controlled) or the device reports it. A mains operated device can be "polled" at regular intervals, not at each call of "getValue".

    Link to comment
    Share on other sites

    Try this on a dimmer:

     

    Please login or register to see this code.

    On my HC, this first prints 0 then 99. I guess Fibaro sends the value and then requests the value, then updates the properties of the device. 

    Link to comment
    Share on other sites

  • Topic Author
  • Yes the value and log change within a tick.

     

    That is not to say that z-wave message was not received a while before and the message has taken some time to process through to log and value change. It is just that both those values change in the same tick when they are changed.

    Link to comment
    Share on other sites

  • Topic Author
  • I don't need to test. You can see this on the interface so I checked that a while back. You see the same on RGB.

    Link to comment
    Share on other sites

  • Topic Author
  • @petergebruers I think more detailed logging. I think I will grab the z-wave log and compare to my log. One for tonight. 

     

    The glue that I was waiting for to dry should be dry. I can go and get on with my woodwork. 

    Link to comment
    Share on other sites

    2 minutes ago, robmac said:

    Yes the value and log change within a tick.

     

    That is not to say that z-wave message was not received a while before and the message has taken some time to process through to log and value change. It is just that both those values change in the same tick when they are changed.

     

     

    @robmac

    @petergebruers

     

    I find this very interesting and must try some of these out...

    .....but I have to ask..

    How do you guys know so much about the inner workings of the HC2

    is it just all reading, experimenting and learning or is there a fountain of knowledge somewhere ?

     

    Link to comment
    Share on other sites

  • Topic Author
  • @AutoFrank born with a touch computervoyance.

     

    There is no fountain.

     

    but before I go anyone any thoughts about the second bit.

     

    "When I get these delays, sometimes lights etc that claim to be switched off/on as the value has changed in HC2 are still burning bright or still dark. "

     

    So HC2 has received the message and updated the log and value but the light is changed a while later?

     

    I just don't get that, I have no evidence but when you fire of a load of messages is there a  possibility that the wrong messages and values go to the wrong device? I can't see that within the switch there can be much delay. But possibly if the wrong returns are mapped to the wrong calls from the zwave queue?

    Edited by robmac
    Link to comment
    Share on other sites

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Reply to this topic...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...