Using client.py with more than one evohome controllers
epicurei opened this issue · comments
client summary two evohome WIFI.txt
my system is composed of two evohome WIFI controllers, with only one active for the moment I have nothing special to report (except in the synchronization phase between controller and sensors / actuators in which exception messages are reported) while with two controllers active at the same time only the first is brought back to the exit from client.py correctly while the second only partially even if during the scan all the parameters were detected as well as for the first, for example as indicated in the annex regarding the names of the zones of the second controller that despite having been scanned are not then reported in the summary below because there are no Schema[01:095571 (evohome)], Params[01:095571 (evohome)], Status[01:095571 (evohome)].
Let me know if you need additional information.
It is not 100% clear to me what your issue is, but I believe you want to use client.py where multiple controllers are visible to ramses_rf?
Although ramses_rf is fully capable of dealing with multiple controllers, it has a strong concept of 'the' main controller (by default, the one it 'sees' first).
Indeed, it will likely scan both system, but client.py will report only on the main controller, although it could easily enough be modified to report on all known TCSs (there is a 1-1 correspondence between a controller and a temperature control system).
Because multiple-controller installations are relatively rare, I am not interested in making this change to the codebase.
To scan/report on a specific controller: you simply have to do is tell client.py which one is the controller you're interested in, there are several ways to do this, but the simplest is ensuring the first one it sees is the one you want:
python client.py monitor /dev/ttyACM0 -x "RQ 01:095571 1F09 00"
... where 01:095571
is the controller you're interested in (this has the added advantage of 'seeing' the controller sooner).
The issue with that, is that it still likely also scan the other system, when you may not need for that to happen, so: use a known_list
:
python client.py monitor /dev/ttyACM0 -c configuration.json -x "RQ 01:095571 1F09 00"
... where configuration.json is like:
{
"config": {
"enforce_known_list": false
},
"known_list": {
"01:095571": {"class": "CTL"},
"18:201230": {"class": "HGI"}
},
"block_list": {
"01:174128": {"class": "CTL"}
}
}
(you can't set enforce_known_list
to True, as it needs to have all the devices in that list)
Or, if you wish to scan both:
{
"main_tcs": "01:095571",
"known_list": {
"01:095571": {"class": "CTL"},
"01:174128": {"class": "CTL"},
"18:201230": {"class": "HGI"}
}
}
Probably, the best solution is to have a JSON file for each system:
python client.py monitor /dev/ttyACM0 -c 01_095571.json -x "RQ 01:095571 1F09 00"
You have partly understood the problem, yes I want to use client.py with multiple controllers visible to ramses_rf, no I do not want to delete the data of one of the two controllers because the purpose is to collect all the data to send / modify them to / with a PLC (ser2net? or modbus / TCP).
To do this I must have all the data divided by controller. the most obvious solution would be that you took care directly of modifying client.py to achieve all this and for you it would be extremely simpler than for me as a neophyte (but you replied that you are not interested) so if you indicated to me at least in which part of client.py I should intervene it would simplify my editing activities in part.
A possible alternative solution could be to use two usb-rf launching two instances of client.py on two different ports with a configuration file for each controller, but the question is ramses_rf and client.py can be used in multi instance?
The client.py tool was never intended for your use-case (although I must admit I am not 100% sure what your use-case is), but was intended (inter alia) for people to appreciate how such as you describe could be done.
The idea is that you use the ramses_rf library using your own code, not client.py (which is itself not part of the library).
You can hook into (event-driven):
from ramses_rf import Gateway
gwy = Gateway("/dev/ttyACM0", **kwargs)
gwy.create_client(process_msg_callback) # if you want to see each msg as it arrives
await gwy.start()
... and for (e.g.) state (polled):
for tcs in gwy.systems:
print(tcs.state) # or tcs.schema, or tcs.params, or tcs.zones, etc.
Everything you need to know is in client.py, although I appreciate it may be difficult for a 'neophyte' to unpick that.
You can have two instances of ramses_rf talking to a ser2net port, but not a USB port. FWIW, I don't think this is the correct solution for you.
In short: you should be creating your own equivalent to client.py.
thank you for the support you provided, Your indications allowed me to get where I wanted and below I report the changes I made to the file client.py that led to the result in the file attached.
If you think it appropriate, please also report them on its official version in order to avoid me in its future versions having to introduce them again
..............
def print_summary(gwy, **kwargs):
# entity = gwy.tcs or gwy
if kwargs.get("show_schema"):
for tcs in gwy.systems:
entity = tcs # gwy.tcs or gwy
print(f"Schema[{entity}] = {json.dumps(entity.schema, indent=4)}\r\n")
# schema = {d.id: d.schema for d in sorted(gwy.devices)}
# print(f"Schema[devices] = {json.dumps({'schema': schema}, indent=4)}\r\n")
if kwargs.get("show_params"):
for tcs in gwy.systems:
entity = tcs # gwy.tcs or gwy
print(f"Params[{entity}] = {json.dumps(entity.params, indent=4)}\r\n")
params = {d.id: d.params for d in sorted(gwy.devices)}
print(f"Params[devices] = {json.dumps({'params': params}, indent=4)}\r\n")
if kwargs.get("show_status"):
for tcs in gwy.systems:
entity = tcs # gwy.tcs or gwy
print(f"Status[{entity}] = {json.dumps(entity.status, indent=4)}\r\n")
.............
client summary sort evohome controller.txt