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

[Jamie mccrostie 82]

28 minutes ago, robmac said:

@Jamie mccrostie

 

Probably something the community can provide better. Fibaro have a lab with known conditions. We each have a unique situation with larger than lab conditions.

 

On the other hand...

I used to post to tell people with issues to turn of polling for the majority of their devices. Fibaro for a long time left it default on.

 

It is amazing how many people would not do this simple thing and used to suffer for it. So Fibaro does have a part to play. For starters all templates for devices that have the potential to create a lot of traffic could start with cautious values. Users would then have to go and increase reporting frequency for those sensors it was important for.

 

 

 

Getting off topic here but the whole fibaro information/instructions secret thing amazes me and the information stuff they have done well like "Elearning" no one knows about.

If it were you wouldnt you put that link on the packaging of the HC's? Or are they trying to keep their help desk staff busy.

May be thats the attraction. The  puzzle to beat all puzzles.

 

Edited March 14, 2017 by Jamie mccrostie

[robmac 173]

Hi @AutoFrank,

 

Last one for the day.

 

The simple answer is no for most devices as he devices tell HC2 when something changes. For those that do not support association then yes you need it. Very few devices can be bought that do not support association now.

 

The only issue can be when something changes when HC2 is not there. This is rare for me now. 

 

Homeseer used to do a one off poll of all devices on start and as @tinman has now alerted me to the poll function HC2 can simply do the same for any devices where it would be an issue.

 

Hope that helps and if you want to help yourself turn it off and later or possibly @tinaman will post an autostart scene that will make sure all your devices are in sync with HC2 on restart.

 

 

Edited March 14, 2017 by robmac

[AutoFrank 372]

36 minutes ago, robmac said:

Hi @AutoFrank,

 

Last one for the day.

 

The simple answer is no for most devices as he devices tell HC2 when something changes. For those that do not support association then yes you need it. Very few devices can be bought that do not support association now.

 

The only issue can be when something changes when HC2 is not there. This is rare for me now. 

 

Homeseer used to do a one off poll of all devices on start and as @tinman has now alerted me to the poll function HC2 can simply do the same for any devices where it would be an issue.

 

Hope that helps and if you want to help yourself turn it off and later or possibly @tinaman will post an autostart scene that will make sure all your devices are in sync with HC2 on restart.

 

 

 

Thanks @robmac, must add that to my list

[petergebruers 1,261]

On 13.03.2017 at 7:18 PM, petergebruers said:

I see. Sounds very plausible. Like you say, some time separation may be needed (actually, in general, more separation may be necessary). Either a deliberate sleep or some reordering of the commands. I think I can't do any more tests before Wednesday (I need to hook up a FGS-223, to test). I'll report back.

 

 

 

So, I didn't connect my spare FGS-223 after all. After I made that promise, @robmac and @tinman posted more information, that seem to explain the observed delays. My short version: Z-Wave has limited bandwidth, and you have to account for communication of other devices + possible reporting of the controlled (switched) device (like: power reporting). For non-technical members this boils down to the advice: put some sleep() between commands and don't send anything that's needed. I got this advice from Fibaro long ago, and I give the advice a few times per year. Thanks to robmac's investigation (and tinman's hidden commands), you can actually get an idea of the performance...

 

On 14.03.2017 at 8:34 AM, Jamie mccrostie said:

Isnt latency the same issue across all wireless based systems zwave, zigbee.....

 

If your traffic gets to a certain ration of the available bandwidth, you'll get collisions and performance tapers of. When you know that limit, you could guestimate what happens if you want to control X devices in Y time, allowing for a bunch of status messages and the usual reporting from the rest of your network. If you exceed bandwidth requirements, nothing can help you... I wouldn't say that is an RF issue per se. Radio issues depend on your environment. Random disturbances because of noise and interference... Distance between devices is a factor. Building materials too.

 

Also routed messages are stored and forwarded on the same network, so delay and bandwidth usage increases if your device cannot communicate directly. I think it's better to have this penalty, than to have no communication at all  

 

I'm not sure of the alternatives. Wires? Reliable, yes, but price... Bluetooth? Nah, crowded 2.4 GHz spectrum, compatibility, nah. Wireless? Crowded 2.4 GHz spectrum, soon to be crowded 5 GHz spectrum. BTW only the lower bitrates of the 802.11 protocol (802.11 b and n about  1 Mbit/s = 10x faster than Z-Wave) have enough reach and penetration. Forget "ac" at high speeds. There is no mesh networking, so you'll have to put your own access points to cover your building. Bandwidth comes at a price too: power consumption (the radio, the processing).

 

If you think I'm just babbling away... You're probably right, I am!

[Sankotronic 2,093]

At the beginning of my journey with Fibaro HC2 I noticed that there are some delays with sending commands to actors and getting confirmation back. So, from beginning I was using small delays between sending commands and also checking feedback from them. That is main reason why I made Main scene for time based events that can be used instead of making too many scenes looping endlessly mostly not doing nothing except consuming HC resources, or even sending too much same commands to the same devices again completely unnecessary.

 

What I really miss on HC2 is some kind of global timer or synchronizer based on clock timer instead of fibaro:sleep function that is completely useless since it can't count in time that is used to execute code if you know what I mean. Is there a way to run code exactly every minute?

 

Sorry if I miss the topic! 

[tinman 1,025]

On ‎14‎.‎03‎.‎2017 at 8:34 AM, Jamie mccrostie said:

Isnt latency the same issue across all wireless based systems zwave, zigbee.....

 

it is not latency due to RF but due to how the protocol ensures that the data has been send and received (ACK frames on pictures page 2) by target device, and if not the (by the protocol defined) re-transmission will be executed and finally (if re-transmission not worked 3 times) different route will be taken. Of course one could just send "on" and hope that a lamp will go on, but this is not how zwave works (luckily). 

[Jamie mccrostie 82]

9 hours ago, petergebruers said:

 

So, I didn't connect my spare FGS-223 after all. After I made that promise, @robmac and @tinman posted more information, that seem to explain the observed delays. My short version: Z-Wave has limited bandwidth, and you have to account for communication of other devices + possible reporting of the controlled (switched) device (like: power reporting). For non-technical members this boils down to the advice: put some sleep() between commands and don't send anything that's needed. I got this advice from Fibaro long ago, and I give the advice a few times per year. Thanks to robmac's investigation (and tinman's hidden commands), you can actually get an idea of the performance...

 

 

If your traffic gets to a certain ration of the available bandwidth, you'll get collisions and performance tapers of. When you know that limit, you could guestimate what happens if you want to control X devices in Y time, allowing for a bunch of status messages and the usual reporting from the rest of your network. If you exceed bandwidth requirements, nothing can help you... I wouldn't say that is an RF issue per se. Radio issues depend on your environment. Random disturbances because of noise and interference... Distance between devices is a factor. Building materials too.

 

Also routed messages are stored and forwarded on the same network, so delay and bandwidth usage increases if your device cannot communicate directly. I think it's better to have this penalty, than to have no communication at all  

 

I'm not sure of the alternatives. Wires? Reliable, yes, but price... Bluetooth? Nah, crowded 2.4 GHz spectrum, compatibility, nah. Wireless? Crowded 2.4 GHz spectrum, soon to be crowded 5 GHz spectrum. BTW only the lower bitrates of the 802.11 protocol (802.11 b and n about  1 Mbit/s = 10x faster than Z-Wave) have enough reach and penetration. Forget "ac" at high speeds. There is no mesh networking, so you'll have to put your own access points to cover your building. Bandwidth comes at a price too: power consumption (the radio, the processing).

 

If you think I'm just babbling away... You're probably right, I am!

Peter  knowledge thru "babbling"  are what forums are all about.

Edited March 17, 2017 by Jamie mccrostie