Mass communication loss overnight?

[Jemster]

I've been thinking about this a bit more...

So the theory is that a continuous transmission extra device would cause an issue, but a momentary transmission one, such as Loop, shouldn't. And I was happy with that as a given, the comms method has to be pretty bulletproof... right??

However, reading up on the phantom override issue, it seems to me there are many situations where the loss of a single Set Point command from the controller would play absolute havoc with the system. If the controller sends out a set-point, and it is missed by the hr92, then the hr92 will report back a different set point up to an hour later and that'll surely make the controller think it has an override?

So if Loop happened to be pulling data from it's meters at just the moment that the EvoHome controller signalled out the Set Points to the zones, the madness could happen.

If multiple zones change set-point at a single time, do these happen simultaneously or are they each signalled out at some point in the 4-minute window? i.e. would there be one big burst of 868MHz data or would I have 'n' bursts scattered over the 4 minutes depending on the hr92? Just wondering because at least one zone with an 11pm set-point did switch ok. And one of the trouble zones made it's last switch at 10:30...

Much as I really like Loop, it may be that compatibility is more out of luck than anything else??

[DBMandrake]

Interesting - I was under the impression the system did a round-robin to bring everything into sync, thus any communication failure on a single update didn't matter because it would get re-sync'd on the next update. Also, if I reboot an HR92, I thought it picked up the correct set point a few minutes afterwards...

Some things are periodically resent, some are not.

If you make an override directly at an HR92 it sends a set point change to the controller within a few seconds - and every hour (counting from the time the HR92 is booted, not when the set point is changed!) it sends another set point change to the controller to "refresh" it with the same value.

In fact this hourly set point update is what causes the phantom override if it happens within the window of opportunity between when a scheduled set point change occurs and when the controller actually gets around to sending the update out to the HR92. (which can be up to 4 minutes, so the window of opportunity can be up to 4 minutes within a 60 minute period) When this happens the set point gets reverted to the previous one and it appears to be a manual override. (clock icon)

So if you reboot the controller at a time when manual overrides are in force the next hourly HR92 set point transmission to the controller sync the controller with the status of that set point.

For BDR91 (and probably the Opentherm bridge as well, but I don't have one to test) a heat demand request is sent from the controller to BDR91 every time there is a change in heat demand. If the heat demand is constant a "refresh" of the last value is sent every 20 minutes. If a BDR91 doesn't receive any updates for 45 minutes the red light will start blinking but it will continue to operate. After 60 minutes the red light will go solid and the relay turns off.

Temperature sensors like DTS92 and HR92 send to the controller periodically - so if one message doesn't go through it just causes a delay in the temperature measurement being updated. The HR92 has a variable update rate for sending temperature readings which sends more often the faster the temperature is changing. I think the DTS92 has a fixed update rate of about every 4 minutes.

The HR92 sends a heat demand update to the controller every time it's heat demand changes (movement of the valve pin position) and I'm not 100% sure but I don't think there is any retransmission of that heat demand if it remains the same for a long period of time. (So a lost heat demand message from HR92 to controller is problematic)

In the controller to HR92 direction two things are sent - temperature sensor updates and set point updates. Both are sent on a regular schedule of about once every 4 minutes. The protocol actually allows the controller to specify a custom "time to next transmission" in each message so in theory it could be varied from one transmission to the next but current firmware sends the same (or very similar) delay every time of a little under 4 minutes.

The temperature sensor transmission from controller to HR92 is made in every 4 minute window however the set point change is only sent if a set point change has occurred. Probably the reason for this is that older Evohome controllers and firmware did not support "local override display", so when you made an override with an HR92 the controller was not aware of the override and did not display it. So if it was to keep resending it's version of the set point it would keep overriding the override you made on the HR92.

[DBMandrake]

Much as I really like Loop, it may be that compatibility is more out of luck than anything else??

I've had Evohome for a year without Loop and two years with Loop now and I can't say I've noticed any real difference in problem rate with Evohome. I have had occasional comms issues before and after.

My Loop gas sender is in the boiler closet as the gas meter is directly above the boiler, so this means my loop gas sensor is within a metre of all three BDR91's and my CS92A as well.

I also have a Bresser 5in1 outdoor weather station on 868.3Mhz on the same side of the house as the boiler, which transmits approximately 6 times per minute. I've only had that since last Christmas and I haven't noticed any worsening of Evohome's performance.

As far as I know devices on 868Mhz are very restricted in how long they're allowed to transmit by regulation - they're only allowed to send very short bursts, not transmit continuously.

I've found the biggest source of comms problems to be standing wave related where one or more devices ends up sitting in a standing wave null point resulting from multi-path reflections - a null that may only be present when moveable objects in the house are in a certain location or not in a certain location!

One example is that I had placed a portable dehumidifier (with a good chunk of metal in it) on the kitchen floor about a metre from the wall where the BDR91's are mounted, and that caused a complete comms loss to one of the BDR91's (but not the other two nearby ones!) for a couple of hours before I noticed it and moved the dehumidifier. It wasn't even plugged in - it was just sitting in the middle of the floor and not even in direct line of sight between controller and BDR91! (presumably the reflection from it was causing a null)

[G4RHL]

One example is that I had placed a portable dehumidifier (with a good chunk of metal in it) on the kitchen floor about a metre from the wall where the BDR91's are mounted, and that caused a complete comms loss to one of the BDR91's (but not the other two nearby ones!) for a couple of hours before I noticed it and moved the dehumidifier. It wasn't even plugged in - it was just sitting in the middle of the floor and not even in direct line of sight between controller and BDR91! (presumably the reflection from it was causing a null)[/QUOTE]

Just a nearby device or electronic panel with a circuit board can cause issues even when not powered up. My garage door control panel would always prevent another wirelessly operated device from working even when there was no power to the door panel. My Netgear Orbi satellite did not function properly and was intermittent when I first had it near to my TV. I have a radio in my study which, if position to close to my iMac, upsets the iMac. The problem is proximity as well as frequency. As DBMamdrake suggests, it is worth carefully checking what other devices are nearby that may cause an issue.

[Jemster]

If you make an override directly at an HR92 it sends a set point change to the controller within a few seconds - and every hour (counting from the time the HR92 is booted, not when the set point is changed!) it sends another set point change to the controller to "refresh" it with the same value.

In fact this hourly set point update is what causes the phantom override if it happens within the window of opportunity between when a scheduled set point change occurs and when the controller actually gets around to sending the update out to the HR92. (which can be up to 4 minutes, so the window of opportunity can be up to 4 minutes within a 60 minute period) When this happens the set point gets reverted to the previous one and it appears to be a manual override. (clock icon)

This has taken me a while to get my head around, but yes, I can see how that happens. However, wouldn't the set-point (as known by the controller) remain on the original setting rather than go to the new setting for up to an hour? i.e. step by step we have:

1. Controller wants to go from T1 -> T2
(delay of up to 4 minutes while controller thinks about sending out T2 Set-Point)
2. Controller receives T1 from HR92 hourly refresh
3. Controller thinks zone is on override to T1
4. Controller finally sends set-point T2 (but still thinks it's at T1 as this queued-send is after the controller internal state mechanism)
(delay of up to an hour waiting on HR92 refresh)
5. Controller receives T2 from HR92 ... problem is corrected

So the controller *thinks* the set-point is T2 only for a couple of minutes between (1) and (2). The rest of the time it thinks the set-point for the zone is T1.

This doesn't echo the log files I'm seeing as they record the set-point as being T2 for periods of an hour (approx. mostly). So I'm thinking what's happening in my situation is:

1. Controller wants to go from T1 -> T2
(delay of up to 4 minutes while controller thinks about sending out T2 Set-Point)
2. Controller finally sends set-point T2 <==== THIS MESSAGE IS SCRAMBLED
(delay of up to an hour waiting on HR92 refresh, controller thinks zone is happily on T2)
3. Controller receives T1 from HR92 ... zone appears to be on override
4. User ends up crying, because the set-point to T2 is never re-sent. Has to wait until next scheduled Set Point before anything changes.

Is the protocol one-way each time? Is it ACK'd by the receiver? i.e. if a collision occurred, would it necessarily be detected and the message re-sent, or is there scope in the protocol for a collision to occur that is not detected?

I've had Evohome for a year without Loop and two years with Loop now and I can't say I've noticed any real difference in problem rate with Evohome. I have had occasional comms issues before and after.

My Loop gas sender is in the boiler closet as the gas meter is directly above the boiler, so this means my loop gas sensor is within a metre of all three BDR91's and my CS92A as well.

I also have a Bresser 5in1 outdoor weather station on 868.3Mhz on the same side of the house as the boiler, which transmits approximately 6 times per minute. I've only had that since last Christmas and I haven't noticed any worsening of Evohome's performance.

As far as I know devices on 868Mhz are very restricted in how long they're allowed to transmit by regulation - they're only allowed to send very short bursts, not transmit continuously.

I've found the biggest source of comms problems to be standing wave related where one or more devices ends up sitting in a standing wave null point resulting from multi-path reflections - a null that may only be present when moveable objects in the house are in a certain location or not in a certain location!

One example is that I had placed a portable dehumidifier (with a good chunk of metal in it) on the kitchen floor about a metre from the wall where the BDR91's are mounted, and that caused a complete comms loss to one of the BDR91's (but not the other two nearby ones!) for a couple of hours before I noticed it and moved the dehumidifier. It wasn't even plugged in - it was just sitting in the middle of the floor and not even in direct line of sight between controller and BDR91! (presumably the reflection from it was causing a null)

My Loop transmitter is outside the front of the house in the gas meter cabinet. My loop receiver is in the hallway in the middle of the house. My EvoHome controller is around the middle of the house also in the Living Room. Initially the Loop receiver was in our 2nd living room but it was too far from the Gas Meter to be reliable. Tricky trying to get all these things within range - our electric meter is almost diagonally opposite our gas meter.

If it were an obstruction, the failure point would have to be around the controller (multiple zones, both incidents), and this is situated in a constant location on a bookcase in a room that is not in daily use. There is a light on the bookcase, but it's regularly on and off and doesn't move around, so I would expect a lot more failures if it were this object. However, I will try moving a few things around and see how it goes.

[Jemster]

One example is that I had placed a portable dehumidifier (with a good chunk of metal in it) on the kitchen floor about a metre from the wall where the BDR91's are mounted, and that caused a complete comms loss to one of the BDR91's (but not the other two nearby ones!) for a couple of hours before I noticed it and moved the dehumidifier. It wasn't even plugged in - it was just sitting in the middle of the floor and not even in direct line of sight between controller and BDR91! (presumably the reflection from it was causing a null)

Just a nearby device or electronic panel with a circuit board can cause issues even when not powered up. My garage door control panel would always prevent another wirelessly operated device from working even when there was no power to the door panel. My Netgear Orbi satellite did not function properly and was intermittent when I first had it near to my TV. I have a radio in my study which, if position to close to my iMac, upsets the iMac. The problem is proximity as well as frequency. As DBMamdrake suggests, it is worth carefully checking what other devices are nearby that may cause an issue.

I will look into this... so hard to find a central position away from everything - what kind of distance are we talking here? There's nothing within a couple of feet of it in any direction at the moment.

[dty]

Is the protocol one-way each time? Is it ACK'd by the receiver? i.e. if a collision occurred, would it necessarily be detected and the message re-sent, or is there scope in the protocol for a collision to occur that is not detected?

There is no positive acknowledgement in the protocol. Some messages are requests which receive an immediate reply, but most are just sent with the assumption that they've arrived or that the periodic repetition will fix any missed messages.

The radios detect if something else is sending, and won't try and transmit at the same time, so the chances of collision are minimal. There is still a small window where two radios both decide that nothing is transmitting and so start transmitting simultaneously, but they should still be able to detect that. Whether the firmware on the device will do anything about it is another matter.

[Jemster]

There is no positive acknowledgement in the protocol. Some messages are requests which receive an immediate reply, but most are just sent with the assumption that they've arrived or that the periodic repetition will fix any missed messages.

The radios detect if something else is sending, and won't try and transmit at the same time, so the chances of collision are minimal. There is still a small window where two radios both decide that nothing is transmitting and so start transmitting simultaneously, but they should still be able to detect that. Whether the firmware on the device will do anything about it is another matter.

And if periodic repetition doesn't occur for Set-Points then this is where it could all go wrong. If there's no acknowledgement on a sent message and both transmitters started at the same time, I doubt they'd detect the message being lost. I'm just not familiar with 868MHz, all my development is UDP and TCP based, but it sounds more like a UDP protocol than the guaranteed delivery you get with TCP.

I'm wondering if what I have here is a fault in the EvoHome control unit hardware.

I'm also wondering if disabling Local Override (read about this, assume it's on the Zone configuration menu) would help... although if the set-point message is lost, it's lost. The HR92 would still be wrong, the Controller would just think it was right that's not much help.

I'm also wondering if the dts92 that went off both times is faulty and started spamming the network, blocking the signals from the controller, before it died.

[dty]

Yes. Honeywell make a thing in their literature about a robust communication protocol, when the reality is that it's anything but. The protocol is completely proprietary, but the UDP analogy is useful.

As for the DTS92 spamming, your Domoticz will have logged that (assuming it's using a radio interface, not the Honeywell API). But it seems unlikely that you've got multiple catastrophic failures simultaneously.