Analyzing evohome RF protocol - site survey

[zxdavb]

I think my answer was in post #12 at: https://www.automatedhome.co.uk/vbul...uestions/page2

I'm being asked to put a nodeRED, mqtt, RESTful, etc wrapper around evohome_rf... Sadly, I just I haven't got time for that.

However, anyone will be able to use evohome_rf as a transport, access it via a protocol (except I haven't fully implemented this as yet).

I would recommend this to you - a native protocol <--> RESTful implementation written in Python would be straightforward.

[EDIT] Actually, thinking about your use-case, you probably want to use evohome_rf as a library, and not as a protocol.

[philchillbill]

I see a major refactor in the --get-schedule code is mentioned for the bleeding-edge branch. Any pointers on how to use it now? It seems to no longer accept (need?) --device-id.

[zxdavb]

Hi, its:

python client.py execute /dev/ttyUSB0 --get-schedule <controller ID> <zone ID>

The zone ID is a two-character hex value 00 to 0B.

(venv) dbonnes@vm-builder ~/c/evohome (bleeding_edge)> python client.py execute /dev/ttyUSB0 --get-schedule 01:037519 00

...

 {
    "zone_idx": "00",
    "schedule": [
        {
            "day_of_week": 0,
            "switchpoints": [
                {
                    "time_of_day": "06:30",
                    "heat_setpoint": 21.0
                },
                {

...

The JSON is compatible with evohome-client.

Although this outputs to STDOUT, the reverse is via a file:
python client.py execute /dev/ttyUSB0 --set-schedule 01:037519 schedule.json

... where the file contains (only) the above JSON.

I'd be interested to see how you get on!

If you want to wrap evohome_rf with some RESTful thing, everything you need is in client.py - you should be able to treat the rest of it as a black box.

[philchillbill]

Thanks. That syntax works better ;-)

I get a lot of

18:37:53.765 078 RQ --- 18:013049 01:154595 --:------ 30C9 001 07 < Validation error
Traceback (most recent call last):
  File "C:\Users\Phil\Domotica\evohome\bleeding\evohome_rf\message.py", line 284, in is_valid
    self._payload = payload_parser(self.raw_payload, self)
  File "C:\Users\Phil\Domotica\evohome\bleeding\evohome_rf\parsers.py", line 197, in wrapper
    assert msg.len == 2  # 12B0, 30C9 will RP to 1
AssertionError

and not a single complete schedule, even on multiple runs. I'm afraid I won't have time to retry much over the next 2 weeks due to my schedule but in the New Year I can help debug if needed.

[zxdavb]

To get rid of the AssertionErrors, use -O, as in:

python -O client.py...

Are you using a HGI80 - all dev on that, but issues with evofw3 - if you want, you can pull latest commit & try again.

[philchillbill]

To get rid of the AssertionErrors, use -O, as in:

python -O client.py...

Are you using a HGI80 - all dev on that, but issues with evofw3 - if you want, you can pull latest commit & try again.

I'm using a nanoCUL for this testing - my 'real' HGI80 is reserved for Domoticz. I'll re-try with the latest code after XMAS.

Just curious why the evohome_Rf library cannot write schedules. IS that a limitation of evofw3?

[zxdavb]

The evohome_rf library can write schedules: python client.py execute /dev/ttyUSB0 --set-schedule 01:037519 schedule.json (where the file contains (only) the JSON from a --get-schedule).

The issue is that the evofw3 can throw more errors that a HGI80 (in essence, the library can handle one lost packet, but not two) - I have switched to testing on that platform for a while to improve resilience... always pull the latest commit, or YMMV.