search

NigelCoxon / Hass-heatmiser

Home Assistant Component for Heatmiser PRT-N Stats
7 stars 2 forks source link

Hass not seeing change after set_temperature in climate.py called #3

Open NigelCoxon opened 3 years ago

NigelCoxon commented 3 years ago

Change the target temp for a stat in the UI debug calls show the _settemperature function is called with the correct argument, and the update sent to the stat. Hass then calls the update function on the stat which returns OK, but the target temperature has not been updated. On the next scan interval, update is called again, which returns the updated value.

I cant see anything untoward in the code - maybe the update call happens too quickly for the stat. It doesnt affect the core functionality, it just takes 12-18 seconds on my system to see the change reflected back in the UI

washboy commented 10 months ago

Happy New Year, @NigelCoxon and @tomtokic !

Can I get confirmation please that the heatmiser_ndc main branch is up-to-date (i.e. Nigel hasn't patched his working install - but not yet updated the repo)?

I ask because my own system had been working extremely well until recent(-ish) HA core updates. I can't be certain but I noticed issues such as those described above that seem to coincide with the new climate entity dialogs in 2023.9.

Since then, there's an almost 50/50 chance that any change I make to set temperature or to mode will fail. In fact, the operation may actually succeed at the stat but not be reflected in the UI. Worse though is that the integration then seems to become inactive/stalled and requires an HA restart (the only way I know of to reload the heatmiser_ndc integration) to get things working and updating stat entities again.

Some context: I had happily been using the Additional-attributes branch (v1.1.6) for some months before a core update (back in Apr/May 2023, I think) that completely killed the RS-485 comms. Tom quickly applied a semaphore patch to his fork of main v1.1.3 and that got things working flawlessly again. He named his patched version 1.1.5 and I've been using that since. There's an outstanding pull request for that patch, btw.

I doubt Tom is using his Heatmiser atm (☀️) so he may not have noticed but have you, Nigel?

I don't have the skills to analyse code but, before I try to determine and document precisely what set of user actions will trigger the issue, I'd like to know that I'm using the most up-to-date code. I'm currently using Tom's v1.1.5 (which is just main v1.1.3 with a small patch). I've already reset my scan_interval and COM_TIMEOUT to default values (I was previously using much faster values with great success and reliability until last September).

NigelCoxon commented 9 months ago

Hi @washboy I think my live system is running the same code as on my repo, but I will check and confirm.

I am also getting frequent errors when I change a target temp, or change hvac mode. Sometimes it succeeds in updating the stat, but sometimes not. I had not linked this to any update in HA, but its possible. I have always assumed that it is caused by noise on the RS485 bus or clashes with my touchpad. I am also still frustrated by the delay in updating the UI after a change. However, my system does not lock up or stall, so that is a new problem to me. I hope to find the time over the next few weeks to improve the integration:

washboy commented 9 months ago

Thanks for responding so quickly @NigelCoxon.

I've still not yet determined exactly how to force an "error" state but I have established that, even when the UI has ceased updating, the stat(s) are still being sent (and reacting to) changes via the UI and via service calls. So the RS485 must be working OK.

Setting the target temperature and HVAC mode manually via the UI (Thermostat Card and Climate Dialog) results in an immediate LED "pulse" on the RS485 i/f and the stat updates and reacts appropriately.

Doing the same via manual "Climate: Set target temperature" and "Climate: Set HVAC mode" service calls has the same effect.

Good so far - but today I thought to keep an eye on the RS485 i/f. When in the error state, the RS485 i/f no longer shows the usual regular scan pulses. I've always presumed that the stats are polled (according to the scan_interval and COM_TIMEOUT) to get their current status (DCB dump?). It makes sense then that, if that polling stops, the UI will stop updating - and the stats' climate entities state history will stagnate too. That's what I meant by "inactive/stalled". Fortunately, the physical Heatmiser system chugs along happily, unaware.

The foregoing is probably no news to you, Nigel but perhaps separate confirmation of your own findings is of some use. It'll be great if you do find time to work on the integration again. I'll be pleased to assist in any way I can.

Oh, btw, are you using @tomtokic 's semaphore patch?

David

tomtokic commented 9 months ago

Yeah, just adding my 2 cents worth in. I’m in Australia, so summer here now, but I created that patch as I have 8 zones/thermostats that I was polling and found that what had changed was that HA started to send them all at the same time and corrupt messages on the bus. So the branch I created was to simply have a bit more flow control for multiple messages being sent from HA. I found it helped a lot fix that issue.

Happy to contribute to this project (especially over your summer) when I am using it. I have an ok level of skills. I am a qualified Computer Engineer but these days am in Sales and only code when I need to for these hobbist needs.

Appreciate all your efforts on this project.

Cheers,

Tom

From: washboy @.> Date: Wednesday, 10 January 2024 at 12:47 pm To: NigelCoxon/Hass-heatmiser @.> Cc: tomtokic @.>, Mention @.> Subject: Re: [NigelCoxon/Hass-heatmiser] Hass not seeing change after set_temperature in climate.py called (#3)

Thanks for responding so quickly @NigelCoxonhttps://github.com/NigelCoxon.

I've still not yet determined exactly how to force an "error" state but I have established that, even when the UI has ceased updating, the stat(s) are still being sent (and reacting to) changes via the UI and via service calls. So the RS485 must be working OK.

Setting the target temperature and HVAC mode manually via the UI (Thermostat Card and Climate Dialog) results in an immediate LED "pulse" on the RS485 i/f and the stat updates and reacts appropriately.

Doing the same via manual "Climate: Set target temperature" and "Climate: Set HVAC mode" service calls has the same effect.

Good so far - but today I thought to keep an eye on the RS485 i/f. When in the error state, the RS485 i/f no longer shows the usual regular scan pulses. I've always presumed that the stats are polled (according to the scan_interval and COM_TIMEOUT) to get their current status (DCB dump?). It makes sense then that, if that polling stops, the UI will stop updating - and the stats' climate entities state history will stagnate too. That's what I meant by "inactive/stalled". Fortunately, the physical Heatmiser system chugs along happily, unaware.

The foregoing is probably no news to you, Nigel but perhaps separate confirmation of your own findings is of some use. It'll be great if you do find time to work on the integration again. I'll be pleased to assist in any way I can.

Oh, btw, are you using @tomtokichttps://github.com/tomtokic 's semaphore patch?

David

— Reply to this email directly, view it on GitHubhttps://github.com/NigelCoxon/Hass-heatmiser/issues/3#issuecomment-1884061219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQUKQBTQ4TGU6G5POQSFH3DYNXXJLAVCNFSM4VPP5FW2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGQYDMMJSGE4Q. You are receiving this because you were mentioned.Message ID: @.***>

NigelCoxon commented 9 months ago

Hi @washboy , @tomtokic It took me a bit of time to remind myself about my code, Home Assistant and Github. Its all gone a bit rusty. Anyway, Ive checked my live running code, and I am using the additional attributes branch, exactly as on my repo.

Ive had a look at the semaphore code in @tomtokic 's repo. I have never seen any parallel calls affecting the comms link, and all the logging I saw (some years ago admittedly) clearly showed the stats being accesses sequentially., but this may have changed since then. I can imagine if the reading the comms link fails somehow, then the semaphore will not be released, which may cause the lockups you have experienced. Ill investigate further.

tomtokic commented 9 months ago

Good point on the lockups Nigel. The parallel calls started happening around 2023.9 for me which is why I amended that piece. Fixed one thing, broke another. 😁

Cheers

Tom

On 11 Jan 2024, at 1:06 am, NigelCoxon @.***> wrote:



Hi @washboyhttps://github.com/washboy , @tomtokichttps://github.com/tomtokic It took me a bit of time to remind myself about my code, Home Assistant and Github. Its all gone a bit rusty. Anyway, Ive checked my live running code, and I am using the additional attributes branch, exactly as on my repo.

Ive had a look at the semaphore code in @tomtokichttps://github.com/tomtokic 's repo. I have never seen any parallel calls affecting the comms link, and all the logging I saw (some years ago admittedly) clearly showed the stats being accesses sequentially., but this may have changed since then. I can imagine if the reading the comms link fails somehow, then the semaphore will not be released, which may cause the lockups you have experienced. Ill investigate further.

— Reply to this email directly, view it on GitHubhttps://github.com/NigelCoxon/Hass-heatmiser/issues/3#issuecomment-1884912904, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQUKQBS3ZRK5UPYRHR6YJR3YN2N4PAVCNFSM4VPP5FW2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGQ4TCMRZGA2A. You are receiving this because you were mentioned.Message ID: @.***>