evohome usb hgi80 problem

akatar · Post by **akatar** » Sunday 04 November 2018 21:33

I did an install on windows and i like to add my evohome.
but the temp = 0 degrees and all i see in the log are errors:
2018-11-04 21:29:47.737 Status: evohome serial: Opening serial port: COM5@115200
2018-11-04 21:29:49.325 Status: evohome: controller detected, ID:0x49911
2018-11-04 21:30:08.981 Status: evohome: controller detected, ID:0x4126a
2018-11-04 21:30:17.940 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2018-11-04 21:30:17.940 Error: evohome: unable to decode payload for command 3ef0
2018-11-04 21:30:19.840 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2018-11-04 21:30:19.840 Error: evohome: unable to decode payload for command 3ef0
2018-11-04 21:30:21.542 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2018-11-04 21:30:21.542 Error: evohome: unable to decode payload for command 3ef0

and 2 evohome controllers?
i tried the last stable version and i am now on the latest beta version, any thoughts why this is happening?

do i need to change the settings in windows harware for the com port?

after the beta:
2018-11-04 21:45:30.048 Status: evohome serial: Opening serial port: COM5@115200
2018-11-04 21:45:31.968 Status: evohome: SYSINFO: d1 2014-02-25 App Ver 25 (2014-01-16) Name EvoTouch Colour
2018-11-04 21:45:36.108 (evohome) Heating (Woonkamer)
2018-11-04 21:45:37.057 (evohome) Heating (Woonkamer)
2018-11-04 21:45:37.602 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2018-11-04 21:45:37.602 Error: evohome: unable to decode payload for command 3ef0
2018-11-04 21:45:41.201 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2018-11-04 21:45:41.201 Error: evohome: unable to decode payload for command 3ef0
2018-11-04 21:45:42.603 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2018-11-04 21:45:42.603 Error: evohome: unable to decode payload for command 3ef0

akatar · Post by **akatar** » Sunday 04 November 2018 22:23

adding:
it seems to work, only the log is full of errors.
and only perment temp change work.
if i choose override, it will go back in a couple of seconds to the old value, permenent change works.

philchillbill · Post by **philchillbill** » Sunday 18 November 2018 10:26

The 'unable to decode 3ef0' has been there forever, you can ignore it. The Honeywell protocol is undocumented and quite a lot of guesswork has been needed by the developers to get this working in Domoticz. From time to time, radio packets are encountered that are not fully understood, but it works anyway so not a real issue.

The setpoint override issue has been there for a few months already and was flagged by a few people (including myself) but it has not been resolved yet. Patience is a virtue, as they say

DanD · Post by **DanD** » Wednesday 21 November 2018 14:14

@akatar

I've just picked up your message. Are you still having problems? If so, here's a couple of changes I'd suggest:

As the HGI80 has detected mutiple Evohome systems (ID: 0x49911 and 0x4126a), you need to tell Domoticz which one is yours. If you've got the Wifi Evohome controller, you can find the correct device ID by pressing and holding 'Device Settings' for 10sec. Enter this value on the Hardware settings page in Domoticz for your Evohome device in Controller ID field.

I've not been able to recreate the failure of manual override setpoint changes within Domoticz on my test system and hence not got anywhere with troubleshooting the problem. One common cause of a setpoint failure, but this would affect both permanent and timed overrides, is when the HGI80 device stops sending messages. This can be caused by a too high message frequency, but is easily fixed by simply unplugging and plugging the HGI80 back in. If you are seeing this problem continuously, could you confirm what browser are you using to control Domoticz?

Dan

akatar · Post by **akatar** » Saturday 01 December 2018 15:35

philchillbill wrote: ↑Sunday 18 November 2018 10:26 The 'unable to decode 3ef0' has been there forever, you can ignore it. The Honeywell protocol is undocumented and quite a lot of guesswork has been needed by the developers to get this working in Domoticz. From time to time, radio packets are encountered that are not fully understood, but it works anyway so not a real issue.

The setpoint override issue has been there for a few months already and was flagged by a few people (including myself) but it has not been resolved yet. Patience is a virtue, as they say

and @dand

so it seems that the override issue is a known problem,
no problem i can sit and wait this out (until it's solved i keep it connected to my somfybox)
something i noticed, if the hgi80 is connected to the somfy a red led is lit on the hgi 80, when connected to domoticz, no led is lit (but works)

the browser i tried are several, chrome, firefox etc.

DanD · Post by **DanD** » Sunday 02 December 2018 12:54

@philchillbill & @akatar

Does the temporary override for a zone ever work successfully for you in Domoticz at the moment? The reason that I ask is that I've set-up my Windows test machine running a compiled version of the latest development code with a HGI80 attached and I still can't reproduce the problem (I've been running an hourly test for the last 24h). I'm able to confirm via the Honeywell app / controller / Web that a zone's has setpoint has been correctly changed. The test I'm doing is making a change to a zone setpoint until about 1h in the future. Any ideas what changes I should make to my Domoticz set-up to test further? Note: my set-up is the Evohome wifi controller with HR92s and a HR91 with no other types of hardware set-up in Domoticz.

Oh and the unlit LED on the HGI80 is OK. It's just that the Domoticz code doesn't know how to control the LED so it just remains off even though the HGI80 is correctly processing messages.

Thanks,

Dan

akatar · Post by **akatar** » Sunday 02 December 2018 19:41

@dand

well, i don't have the wifi version, i have the colorscreen with the gateway version and i don't use thermostats. i use only the screen and the opentherm module.

StanHD · Post by **StanHD** » Sunday 02 December 2018 20:53

Hi, thought I would check my system with the timed override:-

Windows 7, Domoticz V4.10215, Hgi80 by USB, Evohome wifi, 6 x Honeywell "Round" thermostats, paired with 4 x HR92 rad valves, and 2 x BDR91 for Wet UFH & Plinth Convector.

Not exactly exhaustive, but a couple of overrides set for 30 minutes and 45 minutes in the future both worked ok.

I do get (for a long time now, but not originally) the "Actuator State" and the "3ef0" errors in the log, but no adverse affects from those.

Please advise if i can assist here with any testing?

DanD · Post by **DanD** » Monday 03 December 2018 12:08

Hi,

Thanks to you both for your helpful replies. I have the older B&W Evohome controller and also a RFG100 which I'll test out in a similar set-up to yours @akatar and see if this helps identify the cause of the temporary override failure.

@StanHD I've got the 'error' messages on my long to-do list. Firstly, I'm considering re-working the messages that are flagged as errors as I don't think unknown commands should be flagged in this way and secondly, I'm gradually expanding the list of identified commands.

Thanks,

Dan

DanD · Post by **DanD** » Monday 03 December 2018 15:46

@akatar

I've tried out my v1 B&W controller and RFG100 and I still can't reproduce the temporary override bug. If possible, could you please paste another example of the first 20 or so lines from the Domoticz log when you restart your Evohome hardware device (ie. the lines you posted in your first message which started with SYSINFO)? Here's an example of what appears in the log with my v3 controller set-up:

Code: Select all

2018-12-03 14:22:22.485 Status: evohome serial: Opening serial port: COM4@115200 
2018-12-03 14:22:24.053 Status: evohome: SYSINFO: d1 2017-11-20 App Ver 99 (2013-08-01) Name Evo Color 
2018-12-03 14:22:25.021 Status: evohome: CONTROLLER_MODE: Setting: (0=Normal) (0=Permanent)  
2018-12-03 14:22:26.036 (EvoUSB) Heating (Hot Water) 
2018-12-03 14:22:26.021 Status: evohome: DHW_TEMP: DHW sensor msg: 0x51d74: 1: 5091 
2018-12-03 14:22:27.028 (EvoUSB) Heating (Hot Water) 
2018-12-03 14:22:27.028 Status: evohome: DHW_STATE: Setting: 1: 1 (0=Auto) 
2018-12-03 14:22:27.270 Status: evohome: ZONE_TEMP: Zone sensor msg: 0x11e3c7: 0: 1680 
2018-12-03 14:22:28.052 (EvoUSB) Heating (Living Room) 
2018-12-03 14:22:28.037 Status: evohome: ZONE_TEMP: Zone sensor msg: 0x51d74: 1: 2116 
2018-12-03 14:22:29.052 (EvoUSB) Heating (Living Room) 
2018-12-03 14:22:29.037 Status: evohome: ZONE_SETPOINT_MODE: Setting: 1 (0x51d74): 2100 (2=TemporaryOverride) 2018-12-03 18:00 
2018-12-03 14:22:30.037 Status: evohome: ZONE_INFO: 1: Min 5.0 Max 35.0 Flags 16 [Local Override Enabled] [Window Function Enabled] [Single Room Zone]  
2018-12-03 14:22:31.068 Status: evohome: ZONE_NAME: 1: Name Living Room 
2018-12-03 14:22:32.068 Status: evohome: DEVICE_INFO: 4: Addr=0 ?=1 ID:0x11e3c9 (4:123849) 
2018-12-03 14:22:33.068 (EvoUSB) Heating (Office) 
2018-12-03 14:22:33.052 Status: evohome: ZONE_TEMP: Zone sensor msg: 0x51d74: 2: 1949 
2018-12-03 14:22:34.083 (EvoUSB) Heating (Office) 
2018-12-03 14:22:34.068 Status: evohome: ZONE_SETPOINT_MODE: Setting: 2 (0x51d74): 1900 (0=Auto) 
2018-12-03 14:22:34.153 Error: evohome: unknown command 0006 
2018-12-03 14:22:34.153 Error: evohome: unknown command 0006 
2018-12-03 14:22:35.099 Status: evohome: ZONE_NAME: 2: Name Office

I'm particularly interested to see if you get any of the CONTROLLER_MODE, ZONE_TEMP, ZONE_SETPOINT_MODE, ZONE_NAME and DEVICE_INFO messages as these are all triggered by Domoticz sending a request via the HGI80 to the Evohome controller. If you're not getting any of these appearing in the log it indicates that the HGI80 isn't successfully sending any messages. If this is the case, could you try disabling the Evohome hardware device in Domoticz by de-selecting it and hitting update and then re-enabling it in a similar way and take a look whether any of these messages appear in the log? This restart can trigger the HGI80 to begin sending again. If this doesn't help, then I think we might need to troubleshoot the relevant COM port settings as these also might be preventing message sending.

Thanks,

Dan

philchillbill · Post by **philchillbill** » Monday 03 December 2018 20:58

Hi Dan,

I'm on Beta 4.10233 with an Evohome WiFi and a HGI80 and I still have the issue (just verified now).

Phil

DanD · Post by **DanD** » Monday 03 December 2018 21:35

Hi Phil,

Do the temporary overrides constantly fail on your system or do they sometimes work? @akatar's problem does appear to be a total HGI80 message send failure based on the info posted to date, but some must work if permanent overrides work OK so it's going to take some time to fully understand.

Dan

philchillbill · Post by **philchillbill** » Monday 03 December 2018 23:18

I don’t use the UI that often for overrides. I use the JSON a lot via Habridge and Alexa with my own Perl script and that always works fine. So I assume it’s more of a UI issue than an engine issue.

Sent from my iPhone using Tapatalk

DanD · Post by **DanD** » Tuesday 04 December 2018 0:06

Thanks Phil,

I've had a look at the Domoticz Evohome code to try and understand why a permanent override might work, but a temporary one fail. There's actually no difference in the commands sent for these two types of override via the HGI80, just small tweaks in the parameters. So my first thought is that there might be some problem with differences between the time/date info set in the UI and the ones stored on the Evohome controller. This might cause a temporary override to be rejected by the controller, but a permanent one would be unaffected. There were some time/date problems previously in Domoticz, but I need to do some further searching as I can't recall the details.

Regards,

Dan

philchillbill · Post by **philchillbill** » Tuesday 04 December 2018 8:52

That could very well be it. If I recall, Domoticz ignores the time zone info in an ISO date.

Sent from my iPhone using Tapatalk

akatar · Post by **akatar** » Thursday 06 December 2018 20:37

DanD wrote: ↑Monday 03 December 2018 12:08 Hi,

Thanks to you both for your helpful replies. I have the older B&W Evohome controller and also a RFG100 which I'll test out in a similar set-up to yours @akatar and see if this helps identify the cause of the temporary override failure.

@StanHD I've got the 'error' messages on my long to-do list. Firstly, I'm considering re-working the messages that are flagged as errors as I don't think unknown commands should be flagged in this way and secondly, I'm gradually expanding the list of identified commands.

Thanks,

Dan

i must say, i downloaded the last beta (6/12) and everythings works as it should.
i did not change anything except the update.

philchillbill · Post by **philchillbill** » Tuesday 11 December 2018 19:19

@DanD

I notice that the until time reported in the Domoticz UI is off by an hour. I have a perl script that I use with Alexa to boost the temperature in a room for a period of 20 mins. All it does is add 20 mins to the current ISO date-time and post a JSON to Domoticz as follows:

Code: Select all

../json.htm?type=setused&idx=600&setpoint=22.5&mode=TemporaryOverride&until=2018-12-11T19:17&used=true

If, after doing this, I look in the Domoticz UI for that zone's setting, it shows as having a TemporaryOverride until 20:17, which is wrong. In reality, it will be 19:17 when the temp bumps back to schedule, it's just showing as 20:17 in the UI. I'm on CET timezone and all clocks are set corrrectly.