* A range extender for larger properties
* An API on the controller for monitoring/home automation
* More than 12 zones (I might have already mentioned that)
* Separation of schedules and zones (so I can make a "downstairs" schedule and apply it to 5 zones)
* Saved schedules so I can easily swap a summer and winter schedule, for example
Range extender would be welcome indeed. Not so much because my home is big but there is a lot of metal in the floors and I tend to lose communication from time to time with units that are two stories up.
Schedule save/restore is actually quite easy. I have an example of it in my c++ evohomeclient project.
The question is whether a "range extender" is even possible with the current over the air protocol design. I'd suggest that if it were, there would already be one available...
Some sort of store and forward approach is the only thing that would work, but receiving devices may be confused by the duplicate messages, and more than one "range extender" wouldn't be possible without a way for them to identify each other so they don't repeat each others repeats endlessly...
Well, it's radio so it's bound to have echo's at some point and hopefully some mechanism to filter messages that should not be there. My guess would be that normal usage without a repeater may see duplicate messages anyway if somehow an ACK gets lost in the lower level protocol.
There's a major difference between an "echo" caused by multi-path propagation and a re-transmission by a repeater. Reflections would arrive within microseconds and overlap the original signal in time, re-transmissions would be sent milliseconds or tens of milliseconds later after the original signal finished. Many orders of magnitude difference in delay.Originally Posted by gordonb3
If all the communications are idempotent and don't expect acknowledgements then re-transmissions a fraction of a second later would probably not do any harm, and whilst we know that many of the communications fall into this category (such as temperature sensors sending temperature measurements) not all may - there may be some commands that expect immediate responses such as the binding process, that would be confused by receiving a second reply.
Also if the protocol itself doesn't have knowledge of repeaters (such as a "repeated by xxx" field) then trying to add more than one repeater would cause a loop with each repeater repeating what the other repeater sent.
Yet another issue - how would your repeater know which devices belonged to your Evohome system and not your neighbours ? Do you want a neighbours repeater intercepting and re-transmitting your system's packets ? What if you and your neighbour both had a repeater within range of each other - now you have a loop.
My opinion from what I've seen of the protocol is that passive or "dumb" repeating of message packets would work after a fashion but cause issues with some aspects of the system such as the binding process. The only way to do it properly within the constraints of the current protocol might be to make the repeater a gateway where devices on one side of the gateway must use the gateway to communicate with devices on the other side of it. EG devices must bind to the repeater.
Last edited by DBMandrake; 11th July 2017 at 02:59 PM.
DanD was working on repeater functionality.
With his system you bound the repeated devices to the repeater. And then bound the repeater to Evohome.
Not sure how far he got....
P.
I think interposing it as a man in the middle like that instead of a dumb repeater is the only way to do it properly. It could make the binding process quite complicated though, and the smart repeater would have to have specific knowledge of each device type to know how to bind it and what kind of device it is.
Yup. So more like an intelligent proxy than a dumb repeater.
Such a shame that meshing wasn't built in from the start (only for the mains powered devices, obviously. The same way Zigbee and ZWave devices do it). That way you could just fire up a BDR91 or whatever (with nothing attached) to fill any voids in the network.
P.
Or, better yet, just build it on top of one of those networks, then we could just leverage existing repeaters, expertise, etc.
I cover my property with two controllers, because of both range and #zones. I am (now) generally happy with this but I would like the ability to choose which zones are displayed on which controller. This would require the controllers to communicate with each other over Ethernet. In some cases I would like the same zone displayed on both controllers.
Having more displayable zones I'm not sure about, maybe it will work or possibly just be confusing.
As my controllers are upstairs/downstairs one end/the other it is very physically inconvenient to have to use both. Also which zones are on which is not intuitive as it isn't a logical upstairs/downstairs separation. Obviously the app interface partially solves this but direct controller/controller awareness would be much more user friendly and aspects of system wide control better.
Last edited by Kevin; 12th July 2017 at 01:58 AM.
Posting Permissions
Reply With Quote