sending commands with evofw3

dystechnic commented 3 years ago

Hi, First off, thank you for the effort in creating this script.

I am trying to send commands but have no success doing so. My setup is a Arduino Nano with a C1101 board I've flashed the nano with evofw3. I'm using these Honeywell components:

Evohome wifi base unit
TRV HR92

R8810 opentherm module This is my devices.json:

{
"01:187875": { "name": "Controller", "zoneId" : 1, "zoneMaster" : false },
"04:042911": { "name" : "Woonkamer", "zoneId" : 1, "zoneMaster" : true },
"04:042907": { "name" : "Achterkamer", "zoneId" : 2, "zoneMaster" : false },
"04:042913": { "name" : "Achterkamer", "zoneId" : 2, "zoneMaster" : true },
"04:042915": { "name" : "Keuken", "zoneId" : 3, "zoneMaster" : true },
"04:170497": { "name" : "Gang", "zoneId" : 4, "zoneMaster" : true },
"04:171837": { "name" : "Bijkeuken", "zoneId" : 5, "zoneMaster" : true },
"04:170491": { "name" : "Zolder", "zoneId" : 6, "zoneMaster" : true },
"04:024005": { "name" : "Sudeerkamer", "zoneId" : 7, "zoneMaster" : true },
"04:024001": { "name" : "Slaapkamer", "zoneId" : 8, "zoneMaster" : true },
"04:024003": { "name" : "Logeerkamer", "zoneId" : 9, "zoneMaster" : true },
"04:008262": { "name" : "Badkamer", "zoneId" : 10, "zoneMaster" : true },
"10:006288": { "name" : "Ketelmodule", "zoneId" : 252, "zoneMaster" : true}
}

Everything is working as expected with the exception of sending commands. For example, I try to modify the set_point of one of the TRV's by sending a Json string

{
"command": "setpoint_override",
"arguments": {
"setpoint": 15,
"zone_id": 1
}
}

to the MQTT topic "evohome/gateway/command". I can see the message on the MQTT bus, but nothing happens. It looks like the message just disappears. Is sending supported with evofw3? Is so, what am I missing?

Regards, Ed.

smar000 commented 3 years ago

Although I was not able to get sending working with evofw3, but to be fair, did not spend much time on it. At the moment, I am still using evofw2.

Maybe try a simpler command like "ping" first and see if you get a response back from the controller?

One other thing to try is change the port configuration in the cfg file to the json format option using COM_PORTS (note the plural), and including the "is_send_port" as below (don't forget to comment out your previous config):

[Serial Port]
COM_PORTS = {"/dev/evoftdi": {"baud" : 76800, "retry_limit": 10, "is_send_port": true}}
#COM_PORT         = /dev/evolistener
#COM_BAUD         = 115200
#COM_RETRY_LIMIT  = 10

If this doesn't work, I can't really suggest else other than maybe ask in the evofw3 repo and confirm whether it supports sending.

dystechnic commented 3 years ago

Thank you for the reply.I will try again the comm port change tonight. In case it still does not work with fw3 I will ask if it is possible at all in the fw3 repo.

Just in case, which branch of evofw2 do you use, and doe sending work with that version?

smar000 commented 3 years ago

Just in case, which branch of evofw2 do you use, and doe sending work with that version?

I am using the fifo branch and yes, sending has been working fine.

dystechnic commented 3 years ago

Hi, It seems sending is working with the uart branch of evofw3. at least, according to ghoti57. But I can not get it to work at this moment. He has reacted to the loggings I send him and suggested that the cotroller address is not the correct address and that's why the messages do not reach the destination. link Are you prepared to look into this? I'm stuck and am still trying to understand all the terminology so I am confused about what is meant by controller. Is it the CUL device or is it the evohome controller for example.

I will do all the tests necessary to help with the progress.

Regards, Ed.

dystechnic commented 3 years ago

It seems that the address of the CUL device in evofw3 is hardcoded to 18:056026. So I added a line to the python code to make shure it was recognised by the script and me while debugging the problem. On line 140 I've added DEVICE_TYPE["18"] = "CUL" # NanoCul device Then, in the evogateway.cfg I've added a line to make sure the script didn't default to address 01:139901 for the evohome controller (the touchscreen thermostate) wich has address 01:187875, which it was doing in my case.

[SENDER]
CONTROLLER_ID = 01:187875

Now, as I send a ping to controller this happens on the serial output:

␑# uart\evofw3 0.4.1
000 RQ --- 18:056026 01:187875 --:------ 313F 001 00
066  I --- 01:187875 --:------ 01:187875 0008 002 FC00
080  I --- 10:006288 --:------ 01:187875 3150 002 FC00
000 RQ --- 18:056026 01:187875 --:------ 313F 001 00
083  I --- 10:006288 --:------ 10:006288 1FD4 003 006D91
065  I --- 01:187875 --:------ 01:187875 3B00 002 FCC8
000 RQ --- 18:056026 01:187875 --:------ 313F 001 00
000 RQ --- 18:056026 01:187875 ----- 313F 001 00
000 RQ --- 18:056026 01:187875 --:------ 313F 001 00
065  I --- 01:187875 --:------ 01:187875 1F09 003 FF0744
066  I --- 01:187875 --:------ 01:187875 2309 030 0001F40101F40201F40301F40401F40501F40601F40701F40801F40901F4
065  I --- 01:187875 --:------ 01:187875 30C9 030 0007CD0107820207810307FC04079105082F06079E07079E080802090820
000 RQ --- 18:056026 01:187875 --:------ 313F 001 00

This is what I see in the events.log

2020-08-28 11:39:02 |1/ - | COMMAND_OUT         | PING : Command SENT                                                                       
2020-08-28 11:39:02 |1/000| DATE_REQUEST        | RQ| CUL EvoDingus          -> CONTROLLER             | Ping/Datetime Sync                 
2020-08-28 11:39:32 |     | COMMAND_OUT         | PING : Command NOT acknowledged. Resending attempt 1 of 5...                              
2020-08-28 11:39:32 |1/ - | COMMAND_OUT         | PING : Command SENT                                                                       
2020-08-28 11:39:32 |1/000| DATE_REQUEST        | RQ| CUL EvoDingus          -> CONTROLLER             | Ping/Datetime Sync                 
2020-08-28 11:40:02 |     | COMMAND_OUT         | PING : Command NOT acknowledged. Resending attempt 2 of 5...                              
2020-08-28 11:40:02 |1/ - | COMMAND_OUT         | PING : Command SENT                                                                       
2020-08-28 11:40:02 |1/000| DATE_REQUEST        | RQ| CUL EvoDingus          -> CONTROLLER             | Ping/Datetime Sync                 
2020-08-28 11:40:32 |     | COMMAND_OUT         | PING : Command NOT acknowledged. Resending attempt 3 of 5...                              
2020-08-28 11:40:32 |1/ - | COMMAND_OUT         | PING : Command SENT                                                                       
2020-08-28 11:40:32 |1/000| DATE_REQUEST        | RQ| CUL EvoDingus          -> CONTROLLER             | Ping/Datetime Sync                 
2020-08-28 11:41:02 |     | COMMAND_OUT         | PING : Command NOT acknowledged. Resending attempt 4 of 5...                              
2020-08-28 11:41:02 |1/ - | COMMAND_OUT         | PING : Command SENT                                                                       
2020-08-28 11:41:02 |1/000| DATE_REQUEST        | RQ| CUL EvoDingus          -> CONTROLLER             | Ping/Datetime Sync                 
2020-08-28 11:41:32 |     | COMMAND_OUT         | PING : Command NOT acknowledged. Resending attempt 5 of 5...                              
2020-08-28 11:41:32 |1/ - | COMMAND_OUT         | PING : Command SENT                                                                       
2020-08-28 11:41:32 |     | COMMAND             | ERROR: Previously sent command 'ping' failed to send. No ack received from controller     
2020-08-28 11:41:32 |1/000| DATE_REQUEST        | RQ| CUL EvoDingus          -> CONTROLLER             | Ping/Datetime Sync

So, to me it seems that the traffic flow TO the controller is oke, but it receives no answer.

To be complete, here is my config file

[Serial Port]
COM_PORTS = {"/dev/ttyUSB0": {"baud" : 115200, "retry_limit": 10, "is_send_port": true}}
#COM_PORT         = /dev/ttyUSB0
#COM_BAUD         = 115200
#COM_RETRY_LIMIT  = 10

[Files]
EVENTS_FILE      = events.log
LOG_FILE         = evogateway.log
DEVICES_FILE     = devices.json
NEW_DEVICES_FILE = devices_new.json   

[MQTT]
MQTT_PUB_TOPIC   = dingus/gateway
MQTT_SUB_TOPIC   = dingus/gateway/command
MQTT_SERVER      = xxx.xxx.xxx.xxx
MQTT_USER        = xxx
MQTT_PW          = xxx
MQTT_CLIENTID    = EvoDingus

[SENDER]
# Only tested with gateway_id's with device type 30:071715. Device ID seems to matter. Tried 30:99999 and had incorrect reply address etc.
# THIS_GATEWAY_ID     = 30:071715
THIS_GATEWAY_ID     = 18:056026
# THIS_GATEWAY_NAME   = EvoGateway
THIS_GATEWAY_NAME   = EvoDingus
COMMAND_RESEND_TIMEOUT_SECS = 30
COMMAND_RESEND_ATTEMPTS= 5
CONTROLLER_ID = 01:187875

[MISC]
LOG_DROPPED_PACKETS = False

I'm convinced that I made an error in the config somewhere but I'm still trying to understand it all and have no clue yet to what is wrong here.

Hope this rings a bell with you ;-)

Regards Ed.

smar000 commented 3 years ago

Hi Ed

I'm a bit pushed for time at the moment, but will try to have a look at the new FW over the coming week. The real work of sending/receiving is done by the firmware. All I do in the script is encode it into the format that it is expecting. The important thing on this script side that you need to be careful of is (a) getting your IDs correct - e.g. your controller ID, and (b) making sure that the baud rate works for the sending (there was a time in the earlier days of the firmware when sending would only work at 76k2, but I think that this has been addressed - but no harm in double checking).

From a quick look at what you have given above (and without knowing your IDs), it does look as if the script is doing its job and sending the command to the firmware.

Anyway, I'll try out the new FW on a spare nanoCUL and will let you know how it goes at my end.

dystechnic commented 3 years ago

Hi,

It's working now. To sum all things up: I'm using evofw3, the uart branch.

I've added a line to the python script: DEVICE_TYPE["18"] = "CUL" # NanoCul device Otherwise the CUL device which has a fixed address in the evofw3 firmware (18:056026. ) is not recognised. I had to specify the controller ID in the evogateway.cfg because it kept defaulting back to an address that does not exist. My evohome.cfg looks lik this now:

[Files]
EVENTS_FILE      = events.log
LOG_FILE         = evogateway.log
DEVICES_FILE     = devices.json
NEW_DEVICES_FILE = devices_new.json

[MQTT]
MQTT_PUB_TOPIC   = dingus/gateway
MQTT_SUB_TOPIC   = dingus/gateway/command
MQTT_SERVER      = xxx.xxx.xxx.xxx
MQTT_USER        = xxxxx
MQTT_PW          = xxxxxxxx
MQTT_CLIENTID    = EvoGateway

[SENDER]
THIS_GATEWAY_ID  = 18:056026
CONTROLLER_ID = 01:187875
THIS_GATEWAY_NAME  = EvoGateway
COMMAND_RESEND_TIMEOUT_SECS = 30
COMMAND_RESEND_ATTEMPTS= 5

[MISC]
LOG_DROPPED_PACKETS = False

And my devices.json is

{
    "01:187875": { "name": "Controller", "zoneId" : 1, "zoneMaster" : false },
    "04:042911": { "name" : "Woonkamer", "zoneId" : 1, "zoneMaster" : true },
    "04:042907": { "name" : "Achterkamer", "zoneId" : 2, "zoneMaster" : false },
    "04:042913": { "name" : "Achterkamer", "zoneId" : 2, "zoneMaster" : true },
    "04:042915": { "name" : "Keuken", "zoneId" : 3, "zoneMaster" : true },
    "04:170497": { "name" : "Gang", "zoneId" : 4, "zoneMaster" : true },
    "04:171837": { "name" : "Bijkeuken", "zoneId" : 5, "zoneMaster" : true },
    "04:170491": { "name" : "Zolder", "zoneId" : 6, "zoneMaster" : true },
    "04:024005": { "name" : "Werkkamer", "zoneId" : 7, "zoneMaster" : true },
    "04:024001": { "name" : "Slaapkamer", "zoneId" : 8, "zoneMaster" : true },
    "04:024003": { "name" : "Kledingkamer", "zoneId" : 9, "zoneMaster" : true },
    "04:008262": { "name" : "Badkamer", "zoneId" : 10, "zoneMaster" : true }
}

It probably didn't work the until today because I had 2 NanoCuls on the netwerk. Both with evofw3, so there where 2 devices with the same address. I removed the test device and everything started working immediately.

So, with a litte change to the script is works as expected. I do have a feature request for the script, but I will make a new issue for that. This case can be closed ;-)

Thank you for your support.

Ed.

smar000 commented 3 years ago

Hi Ed

Great to hear that you have it all working, and you are most welcome! I will also look into the new evofw3 in the next few days, and put out any updates as required.

smar000 / evoGateway

sending commands with evofw3 #16