Evohome HGI80 not processing all JSON commands

[philchillbill]

With the latest stable release 4.10717, I notice that my HGI80 regularly ignores commands sent via JSON to Domoticz. The response is the normal

Code: Select all

  {
   "status" : "OK",
   "title" : "SetUsed"
  }

to a command such as

Code: Select all

  ../json.htm?type=setused&idx=601&setpoint=16.0&mode=TemporaryOverride&until=2019-05-22T13:54Z&used=true

but 60-70% of the time nothing will actually happen. The inaction is visible both from the Domoticz API and the TCC app, where nothing changes.

Any ideas?

[DanD]

Hi Phil,

Just a couple of quick clarification questions:

• Does this appear to be a new problem in the current beta release ie. did these JSON commands work reliably in previous versions or did they also sometimes fail?

• Can you tell whether the setpoint change is actually sent by the HGI80 via messages in the Domoticz log?

I don't use this approach myself, but I'll try and create a test set-up to see if I can confirm this behaviour and troubleshoot what might be causing this.

Regards,

Dan

[philchillbill]

Hey Dan,

Thanks for the fast response.

On the first point, I'm not sure. I only ever sent a few commands a day this way and it always worked. However, I'm testing something new so trying out varied/successive commands to check. I notice the failures if I send a few commands within a few minutes, so it may have been that way when I was on the Beta's too - I'd just never have noticed. If I send nothing for say 10 mins, the first command will always succeed. If I send 3 commands within say 5 mins then the 2nd or 3rd will fail.

On the second, there's nothing in the log.

By the way, what is the difference between sending a &mode=FollowSchedule vs &mode=Auto ?

Regards, Phil

[DanD]

Hi Phil,

I've done some testing sending regular JSON requests to make different temporary overrides to a zone setpoint separated by approx 30secs and confirmed successful result via the TCC app. I've tested this on the latest stable release 4.10717 and also my current development beta which is slightly behind the latest stable release. Note: I'm sending my JSON requests via a browser on the same machine running Domoticz. I see the following message in the log after each command is received which also helps confirm that the Domoticz server has received the message:

2019-05-23 11:34:29.107 Status: EventSystem: reset all device statuses...

Any ideas what other things I might check/tweak to help troubleshoot?

Regards,

Dan

[philchillbill]

Hi Dan,

I do see those status messages (didn't realise they were Evohome related). Could it be that the Zulu time I'm specifying is causing the issue? What does Domoticz do internally with the 'until' time specified in the JSON?

Phil

[DanD]

Hi Bill,

I believe that the time specified in your JSON query is sent directly to the Evohome controller, but I'm not 100% sure. If there's any difference between Domoticz & Evohome's time zones then it might cause problems. However, I wouldn't expect that this would cause a larger number of your overrides to fail unless there might be a problem with the time calculation and some are being interpreted as being in the past.

Oh, and I'm really not sure what the difference is between the 'Auto' and 'FollowSchedule'.

Regards,

Dan

[philchillbill]

Thanks Dan. I'll play around a bit with the time-formatting and see if it makes a difference. It's the only variable that I see as a possible culprit.

One question - do you have any idea if Evohome is smart enough to ignore senseless commands? Say the livingroom is at 24 deg actual with a setpoint of 16. Raising the setpoint to say 18 for an hour will have no effect, for obvious reasons. Maybe TCC accepts that but the HGI80 has additional logic to simply ignore such a command. Just a guess.

[DanD]

Hi Phil,

Hmm, good question. I'm not 100% sure I understand though. You mentioned TCC in your last message, but any changes would only be visible here after they had already been confirmed by the controller.

If you're sending commands via JSON to a specific device ID in Domoticz which is connected to Domoticz via the HGI80 hardware device then the complicated message flow for a temporary override is:

Domoticz -> HGI80 -> Evohome controller -> Evohome Zone device

The controller will also send the current setpoints & temperatures for all zones to TCC upon request (via app, website etc). I'm pretty certain that all valid setpoints are accepted irrespective of current temperature. When I was testing I was moving setpoint up & down every 30secs, but always below current temperature. The temporary override message which is sent by the HGI80 via Domoticz is identical to the one which would be sent by altering the setpoint on an actual zone device e.g. turning the top of a HR92.

Regards,
Dan

[philchillbill]

Yep, I understand the flow. Sorry if I was unclear: What I meant was that if TCC is changed directly from e.g. the iOS app it might accept any old changes, whether 'sensible' or not. These would then percolate downwards from the cloud to the Evotouch and to Domoticz UI. I was surmising that for the opposite direction flow, the HGI80 might reject 'senseless' changes and not pass them to the Evotouch, which in turn would of course mean that they would not percolate upward to TCC. When my JSON is being ignored, it's not showing in Domoticz, nor on the Evotouch, nor on TCC (via iOS). So I'm guessing that what might tbe happening is that Domoticz processes the JSON and forwards to the HGI80, it 'rejects' the command, Domoticz UI reverts more or less immediately to the unchanged state because that's what it gets back from the HGI80, finally TCC stays as-is. Just a guess.

By the way, did you ever have any luck editing the schedule using the HGI80?

[DanD]

Hi Phil,

Thanks for explaining further. I'm pretty sure that the HGI80 just sends any correctly formatted message. The only exception to this is if you attempt to send far too many messages in succession, but this limit is something like a sustained 3-4 messages per second. This triggers the HGI80 to reject any further messages and I assume it's part of its conforming to spectrum licencing, but I haven't found any documentation which accurately describes this limit though. When this happens the HGI80 must be reset by either unplugging or restarting the serial connection.

I'm pretty sure your JSONs are unlikely to trigger this as you'll see 100% message send failure once the limit has been exceeded. Note: the HGI80 does continue to process received messages so it can sometimes be hard to troubleshoot as most users don't send many messages via the HGI80.

Yes, I've got a working prototype Python schedule backup and restore. I planned to do some more work before publishing to Github and it'll take a lot more work to integrate into Domoticz as it'll need JavaScript to capture filenames etc which I struggle with. I'll take another look at my Python code and see if I can get it ready for publishing to Github as this would at least allow others to test it out. I think people will find it useful as it allows the entire schedule for all zones to be backed up and restored via ascii files. Hence, bulk changes to schedules can be made very easily.

Regards,

Dan

[philchillbill]

Thanks Dan. I’ll continue to see if I can debug.

I’d *love* to play with that Python code for schedules via HGI80. No worries that it’s not part of Domoticz (yet). For example, a bunch of switches could be set up in Domoticz to trigger via their on/off actions a set of preset schedules stored in json dump files. So e.g. late start tomorrow or early to bed tonight could swap out a whole schedule easily. Not integrated into the Domoticz UI as such but still operable and highly useful !

EDIT: I think I've found the explanation. The temperature has to change between JSON calls and not just the until time. If I send JSON to e.g. set 16 deg until 22:00, my subequent JSON asking for the same 16 but until (say) 22:15 is ignored - nothing goes through unless the temp is different to the current setpoint. Can you perhaps verify that in your setup?

[DanD]

Hi Phil,

I can't seem to reproduce this behaviour on my set-up (stable release 4.10717). JSON requests changing only the temporary until time (forwards or backwards) seem to be reliably accepted and the change is confirmed via the TCC app.

Regards,

Dan

[philchillbill]

Oh boy. I reinstalled the latest stable again via sudo ./updaterelease and all is well. Had also noticed some zwave weirdness so just took a shot. Now all JSON goes through just fine.

Never had an install go bad before. I’m on an Intel NUC with a real SSD so no SD corruption suspected here. You learn every day...


Sent from my iPhone using Tapatalk

[DanD]

Hi Phil,

Thanks for the update and I'm really pleased to hear that you've fixed your problem. It definitely seemed a strange one, I guess some weird part of the installation was corrupted, but very strange that it caused intermittent problems.

Regards,

Dan