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

[tinman 1,070]

54 minutes ago, petergebruers said:

 

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".

 

one can poll manually, but afaik this works only for available devices, if device is marked as dead, poll will skip it. Sure, one can send wakeUpAllDevices or wakeUpDeadDevice before poll. The other hidden function rangeTestStart  (+ rangeTestStop at the end) is good as well, it does nothing else than basic on/off but when device was marked as dead and goes available again, the test returns "ok" immediately, so it good for range stress testing (as designed) 

 

 

[robmac 173]

I take it back there is a fountain of knowledge,

[robmac 173]

More glue time,

 

So the delays in my log correspond with devices where I am calling the second interface of the node immediately after the first interface. So my next question.

 

Is that because the node is busy or because the node's representation in HC2 is busy?

 

I can see no evidence that messages are swapped so there must be an explanation at the device or lamp end.

 

OK,

 

Two cases:

 

Without power monitoring it looks like the device is busy for the fraction of time after the first interface reports. the subsequent command goes in a retry with a wait.

 

Please login or register to see this code.

 

 

the second is more complex as the power metering messages from the first interface start coming through. Still tracing this through but these are the ones with a longer delay. I suppose I should not be surprised.

 

So all I can say is:

 

if you want to avoid delays in a scene that switches many devices make sure you do not list the two parts of a single node side by side in your code. This way the chances the node will be busy still processing the original action (and associated power change) will be reduced when the next action is transmitted.

 

A small detail.

 

 

 

 

Edited March 13, 2017 by robmac

[petergebruers 1,268]

1 hour ago, robmac said:

More glue time,

 

So the delays in my log correspond with devices where I am calling the second interface of the node immediately after the first interface. So my next question.

 

Is that because the node is busy or because the node's representation in HC2 is busy?

 

I can see no evidence that messages are swapped so there must be an explanation at the device or lamp end.

 

 

 

Interesting! I've tried to reproduce this, but my first attempt failed. I may have misunderstood... See comments in the code:

 

Please login or register to see this code.

It makes an interesting noise though, reminds me of the "stepping switch" rattle of old PABX systems.

 

Please login or register to see this link.

Edited March 13, 2017 by petergebruers

[petergebruers 1,268]

1 hour ago, robmac said:

(...)

Without power monitoring it looks like the device is busy for the fraction of time after the first interface reports. the subsequent command goes in a retry with a wait.

 

Please login or register to see this code.

 

 

the second is more complex as the power metering messages from the first interface start coming through. Still tracing this through but these are the ones with a longer delay. I suppose I should not be surprised.

(...)

When you say: "without power monitoring", do you mean you changed the parameters of this particular device?

I was thinking... is this a delay in Z-Wave handling by the device, by the HC or does the status change (or changes, like power and on-off) trigger some scenes, that cause CPU and more access to the device? Just a long shot...

[robmac 173]

I think that is slightly different case. It would be difficult to distinguish the messages for that one in the log.

 

It is a special instance of the less impacted case as no power messages for the device to process and send to HC2.

 

My code switches 125 and then 127 in a long stream of commands that change other devices. It does not toggle one device back and forth.

 

Have you looked at the logs?  I am guessing you also get the retry but as all of the commands are for the same device there might be something else happening to aggregate the impact.

 

 

 

[robmac 173]

I think it is a combination of device and z-wave busy. If the device is busy and z-wave is busy the retries take a long time to work through.

 

If the device has power measurement then it stays busy for longer + it makes the z-wave busy.

 

So you turn off the device and get a confirmation message. Then the device sends new power readings as it is associated but at the same time the other interface is being switched off. This is when I am seeing the retry.

[petergebruers 1,268]

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.

 

 

[robmac 173]

Your code is very different.

 

Mine only sends the next after the previous has reported back so would not fill the buffer unless something else happens on the network at the same time.

[petergebruers 1,268]

2 minutes ago, robmac said:

Your code is very different.

 

Mine only sends the next after the previous has reported back so would not fill the buffer unless something else happens on the network at the same time.

Not only that... My test device has no power reporting... FGS-221... I know, I've said "212" in my code but that was a typo... So yeah, forget it... Sorry!

[robmac 173]

Don't be it is interesting to understand more about how the network behaves.

 

I think my delays are mainly due to network traffic. The times got a lot worse when my heating switched on and the temperature changes came flooding in.

 

 

 

[robmac 173]

7 hours ago, tinman said:

 

one can poll manually, but afaik this works only for available devices, if device is marked as dead, poll will skip it. Sure, one can send wakeUpAllDevices or wakeUpDeadDevice before poll. The other hidden function rangeTestStart  (+ rangeTestStop at the end) is good as well, it does nothing else than basic on/off but when device was marked as dead and goes available again, the test returns "ok" immediately, so it good for range stress testing (as designed) 

 

 

you fountain of knowledge 

 

I like those

Please login or register to see this code.

 

 

[robmac 173]

Hi @tinman,

 

Does

Please login or register to see this code.

only report direct communication?

 

and is it supported by all devices or just more recent fibaro?

 

cheers,

 

Robert

 

Edited March 13, 2017 by robmac

[tinman 1,070]

rangeTestxxxx sends basic set command on / off to the device, the manufacturer is here not important. When the device is fast enough, one can see no transmission errors (here old fibaro Relais, no metering support)

 

Please login or register to see this attachment.

 

 

where of course, cause by metering reports and other factors, other devices might have problems with communication while sending lot of rangeTestxxx frames (3rd part zw300 plug):

 

 

Please login or register to see this attachment.

Please login or register to see this attachment.

 

another example: send to two kind of devices, one slow and one fast responding: already lot of checksum errors, but from time to time success

 

Please login or register to see this attachment.

 

and finally send two exact the same device but with "two threads", so the device have no time to respond

 

Please login or register to see this attachment.

 

i hope this help you to understand what rangeTestxxxx is doing (basically only basic set and waiting for ack)

 

Note: of course if zniffer not perfect tool as it have to receive frames as well and it have its own max banwidth

 

Edited March 14, 2017 by tinman

[robmac 173]

Thanks @tinman

 

Well that is simple and useful.

 

I have run through a few times last night and can see that my network just gets busy. The more busy it gets the more it has to work with retry so the whole thing quickly graduates to pauses.

 

I can now go and tune down some of the reporting from my temperature and power sensors so they are less chatty. I really do not need a blow by blow temperature change or power change in most places. I knew my network got congested but it was complicated to work out where the blocking is. HC2 software layer - z-wave - network -device.

 

I had ruled out the buffer with my code waiting to send new calls. This call gave me a very simple way to see very easily the difference  in runs by just calculating the % fail rate not trying to work out from a few slower responses. When my heating is in a steady state %fail less. Run a bath and the sensors start chatting away and % fail increases.

 

Possibly Fibaro should consider defaulting to less regular reporting from devices. They eventually made the sensible move and changed the default from polling to non polling?

 

Alternatively roll on HC3 and getting my complete network on new chips with higher bandwidth.

 

Robert

 

 

 

[Jamie mccrostie 82]

2 minutes ago, robmac said:

Thanks @tinman

 

Well that is simple and useful.

 

I have run through a few times last night and can see that my network just gets busy. The more busy it gets the more it has to work with retry so the whole thing quickly graduates to pauses.

 

I can now go and tune down some of the reporting from my temperature and power sensors so they are less chatty. I really do not need a blow by blow temperature change or power change in most places. I knew my network got congested but it was complicated to work out where the blocking is. HC2 software layer - z-wave - network -device.

 

I had ruled out the buffer with my code waiting to send new calls. This call gave me a very simple way to see very easily the difference  in runs by just calculating the % fail rate not trying to work out from a few slower responses. When my heating is in a steady state %fail less. Run a bath and the sensors start chatting away and % fail increases.

 

Possibly Fibaro should consider defaulting to less regular reporting from devices. They eventually made the sensible move and changed the default from polling to non polling?

 

Alternatively roll on HC3 and getting my complete network on new chips with higher bandwidth.

 

Robert

 

 

 

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

[robmac 173]

Hi @Jamie mccrostie,

 

Yes absolutely and I have no issue with this other than it is difficult with the out of the box tools to make best use of the bandwidth. All I want to avoid are those times when you control a light and wait 5s for it to turn on the other related lights or a motion sensor gives me a pause after it detects movement before I see the result.

 

This does not happen often but now I can try to avoid it. I was also still in the old world with memories of fibaro issues. I think I have satisfied myself that my issue now is purely congestion on a complicated network that lives in a house with thick walls.

 

This is a slightly better way for me to get an average picture and experiment to get the best possible out of the system in my particular situation without getting specialist tooling.

 

It would actually be very easy to overlay this type of test on a node connectivity diagram if we could easily get the node neighbors and identify hot spots in the network. In the early days I had my old homeseer connected as a secondary so I could get that map of my network. @tinman, any other hidden calls in the box?

 

I think a network all based on the 5 gen chips will solve a lot of my issues due to the higher bandwidth.  I will then be able to just let the system do what the system does out of the box with my size of network. Bring on the HC3.

 

I am still sure zwave is better for me than a system cobbled together with relatively high power drain bluetooth that needs lots of repeaters that add no value but eat power and all those pads and tv thingies I would need. But we have a marketing war now and bluetooth has a massive install base so who knows.

 

BR,

 

Robert

 

[Jamie mccrostie 82]

11 minutes ago, robmac said:

Hi @Jamie mccrostie,

 

Yes absolutely and I have no issue with this other than it is difficult with the out of the box tools to make best use of the bandwidth. All I want to avoid are those times when you control a light and wait 5s for it to turn on the other related lights or a motion sensor gives me a pause after it detects movement before I see the result.

 

This does not happen often but now I can try to avoid it. I was also still in the old world with memories of fibaro issues. I think I have satisfied myself that my issue now is purely congestion on a complicated network that lives in a house with thick walls.

 

This is a slightly better way for me to get an average picture and experiment to get the best possible out of the system in my particular situation without getting specialist tooling.

 

It would actually be very easy to overlay this type of test on a node connectivity diagram if we could easily get the node neighbors and identify hot spots in the network. In the early days I had my old homeseer connected as a secondary so I could get that map of my network. @tinman, any other hidden calls in the box?

 

I think a network all based on the 5 gen chips will solve a lot of my issues due to the higher bandwidth.  I will then be able to just let the system do what the system does out of the box with my size of network. Bring on the HC3.

 

I am still sure zwave is better for me than a system cobbled together with relatively high power drain bluetooth that needs lots of repeaters that add no value but eat power and all those pads and tv thingies I would need. But we have a marketing war now and bluetooth has a massive install base so who knows.

 

BR,

 

Robert

 

 

Like anything fast, tuning is the key.

Where is the "Fibaro Best Coding Practices" for a latency free experience ?

Another "They will work it out for them selfs...."

[robmac 173]

@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.

 

 

Edited March 14, 2017 by robmac

[AutoFrank 372]

4 minutes ago, robmac said:

I used to post to tell people with issues to turn of polling for the majority of their devices.

 

Hi @robmac

 

I'm curious about this - would this not impact the HC2 ability to get device status info (sorry if this is basic, I'm still trying to learn the basics of zwave and the HC2)

 

thanks

-f