Setting Schedules about ramses_rf

[zxdavb]

@smar000 You don't mention which version of the library you are using - 'current master' is a good hint, but things can/do change very quickly... There have been a lot of changes recently...

I should start by admitting I have no automated test suite...

In short, this used to work fine. However, it was never robust, and was more proof-of-concept. It is broken now, only because of changes made elsewhere in the library.

I will look at it, get it working again and let you know.

[zxdavb]

What's your use-case?

[zxdavb]

OK, look now - note the out put of:

python client.py execute /dev/ttyACM0 --get-schedule 01:145038 01

... has changed recently. That is, check the structure of your schedule.json file.

Then see:

python client.py execute /dev/ttyACM0 --set-schedule 01:145038 schedule.json

client.py: Starting ramses_rf...
22:52:51.784 Allowing packets with device_id: 18:006402 (is active gateway?), configure the known_list/block_list as required
22:52:51.785 Won't create a non-allowed device_id: 18:006402 (if required, add it to the known_list)
22:52:51.783 || HGI:006402 | NUL:------ |  I | puzzle_packet    |      || {'ramses_rf': 'v0.14.24', '_parser': 'v0.14.24'}
22:52:51.867 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0101 || {'zone_idx': '01', 'frag_index': 1, 'frag_total': 3, 'frag_length': 41, 'fragment': '68DE6DCCB10D80300C0551DB710C03515052310303300B73320A440111E0527D9D9C
22:52:51.876 || CTL:145038 | HGI:006402 |  I | zone_schedule    | 0101 || {'zone_idx': '01', 'frag_index': 1, 'frag_total': 3, 'frag_length': 41, 'fragment': ''}
22:52:51.938 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0101 || {'zone_idx': '01', 'frag_index': 1, 'frag_total': 3, 'frag_length': 41, 'fragment': '68DE6DCCB10D80300C0551DB710C03515052310303300B73320A440111E0527D9D9C
22:52:51.967 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0102 || {'zone_idx': '01', 'frag_index': 2, 'frag_total': 3, 'frag_length': 41, 'fragment': 'A1AFFB6EFB39FAEEDD46FFDFCD59648AA729780A9E82A7E01978069E8167E025F012
22:52:52.343 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0102 || {'zone_idx': '01', 'frag_index': 2, 'frag_total': 3, 'frag_length': 41, 'fragment': 'A1AFFB6EFB39FAEEDD46FFDFCD59648AA729780A9E82A7E01978069E8167E025F012
22:52:52.351 || CTL:145038 | HGI:006402 |  I | zone_schedule    | 0102 || {'zone_idx': '01', 'frag_index': 2, 'frag_total': 3, 'frag_length': 41, 'fragment': ''}
22:52:52.412 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0103 || {'zone_idx': '01', 'frag_index': 3, 'frag_total': 3, 'frag_length': 31, 'fragment': 'E039780E5EBEFEB677A52DF66F5FAFB4F5E30578015E80178D77006F8713D1'}
22:52:52.431 || CTL:145038 | HGI:006402 |  I | zone_schedule    | 0103 || {'zone_idx': '01', 'frag_index': 3, 'frag_total': 0, 'frag_length': 31, 'fragment': ''}

It's a bit messy, but is working again.

[smar000]

@smar000 You don't mention which version of the library you are using - 'current master' is a good hint, but things can/do change very quickly... There have been a lot of changes recently...

Sorry, version 0.14.24 of the library.

In short, this used to work fine. However, it was never robust, and was more proof-of-concept. It is broken now, only because of changes made elsewhere in the library.

Ah ok! I didn't realise it was there until the other day, so wasn't sure if it was ready for general use etc, but thought to give it a go.

What's your use-case?

I was going to add it to the mqtt gateway, both for getting schedules and setting, ultimately for use from my openHAB system (I have a web based gui front end for evohome schedules, which currently works through the web API).

[smar000]

OK, look now - note the out put of:

python client.py execute /dev/ttyACM0 --get-schedule 01:145038 01

... has changed recently. That is, check the structure of your schedule.json file.

Then see:

python client.py execute /dev/ttyACM0 --set-schedule 01:145038 schedule.json

client.py: Starting ramses_rf...
22:52:51.784 Allowing packets with device_id: 18:006402 (is active gateway?), configure the known_list/block_list as required
22:52:51.785 Won't create a non-allowed device_id: 18:006402 (if required, add it to the known_list)
22:52:51.783 || HGI:006402 | NUL:------ |  I | puzzle_packet    |      || {'ramses_rf': 'v0.14.24', '_parser': 'v0.14.24'}
22:52:51.867 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0101 || {'zone_idx': '01', 'frag_index': 1, 'frag_total': 3, 'frag_length': 41, 'fragment': '68DE6DCCB10D80300C0551DB710C03515052310303300B73320A440111E0527D9D9C
22:52:51.876 || CTL:145038 | HGI:006402 |  I | zone_schedule    | 0101 || {'zone_idx': '01', 'frag_index': 1, 'frag_total': 3, 'frag_length': 41, 'fragment': ''}
22:52:51.938 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0101 || {'zone_idx': '01', 'frag_index': 1, 'frag_total': 3, 'frag_length': 41, 'fragment': '68DE6DCCB10D80300C0551DB710C03515052310303300B73320A440111E0527D9D9C
22:52:51.967 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0102 || {'zone_idx': '01', 'frag_index': 2, 'frag_total': 3, 'frag_length': 41, 'fragment': 'A1AFFB6EFB39FAEEDD46FFDFCD59648AA729780A9E82A7E01978069E8167E025F012
22:52:52.343 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0102 || {'zone_idx': '01', 'frag_index': 2, 'frag_total': 3, 'frag_length': 41, 'fragment': 'A1AFFB6EFB39FAEEDD46FFDFCD59648AA729780A9E82A7E01978069E8167E025F012
22:52:52.351 || CTL:145038 | HGI:006402 |  I | zone_schedule    | 0102 || {'zone_idx': '01', 'frag_index': 2, 'frag_total': 3, 'frag_length': 41, 'fragment': ''}
22:52:52.412 || HGI:006402 | CTL:145038 |  W | zone_schedule    | 0103 || {'zone_idx': '01', 'frag_index': 3, 'frag_total': 3, 'frag_length': 31, 'fragment': 'E039780E5EBEFEB677A52DF66F5FAFB4F5E30578015E80178D77006F8713D1'}
22:52:52.431 || CTL:145038 | HGI:006402 |  I | zone_schedule    | 0103 || {'zone_idx': '01', 'frag_index': 3, 'frag_total': 0, 'frag_length': 31, 'fragment': ''}

It's a bit messy, but is working again.

Great, thanks! Appreciate you looking at it so quickly.

[zxdavb]

BTW ramses_rf can pull the DHW schedule when the TCC web client cannot.

Please understand - client.py is not 'supported' nor 'stable' in any reliable sense, and neither is discovery.py.

You should focus on using:

zone = gwy._evo._get_zone(zone_idx)
schedule = zone.get_schedule() 
   ...
zone.set_schedule(schedule) 

[smar000]

Thanks and understood!

[zxdavb]

@smar000 Unrelated, but your system is one of the few that has these 11s in the 3EF0 payload:

RP --- 10:142568 01:139901 --:------ 3EF0 006 0025110500FF

Now that it's Winter, a 24h log from you, including a discovery, could be really inciteful.

[smar000]

Now that it's Winter, a 24h log from you, including a discovery, could be really inciteful.

Sure, will start one tonight.

[smar000]

packets.log.gz
@zxdavb Log file over the last 24 hours attached. Hope this helps, and do let me know if you need anything further.