Node ids don't seem reliable for extracting thermostat information

[WasserX]

Hi, first of all, thank you for this great contribution! It was a big gap in my setup :)

I tried using the component, but I found that the node ids that are set in the code do not actually appear in the response from my system. I did a couple of modifications and I'm happy to open a PR if you're OK with it, hopefully they also work in your setup.

What have I done?

• I'm using name instead of id as I feel there is a pattern on the conventions used by salus (Obviously I only have my response to test!) - For reference, I have > 10 thermostats so in my case, my response is actually in 2 different nodes.

• Although I'm not too versed in python, I changed a bit the extraction function to avoid iterating/filtering over big lists so many times. As this is executed quite frequently (In the current setup, every 2 seconds), the less time we spend on it, the less load on the system, the better :)

  • I do not have a "Hot Water" system, so I did not touch that section.

• After trial and error I have decoded some more MODES, only to find that someone already did it, so I have completed the list and merged the Presets with the RUN_MODES, as I didn't see a reason for some of them not to show up.

  • You can't show the MODE information and a Preset in HA, the information on the entity comes from the preset property. (e.g. You can't really show that the thermostat is in "Auto - Currently High" whilst having the preset to "Auto") - If you do that, HA will show the MODE but the preset will be left blank. I have as such opted for matching the MODE elements to their RUN_MODES counterpart.
  • For "Party" and "Away", as there was no "time" passed, it was misbehaving on my thermostat, so I have left a placeholder to pass a 'duration' for it, currently hardcoded to 1 day/hour.

• Parameters added:

  • Added a new "refresh interval" parameter. This is because I am worried about hitting the salus endpoint too frequently and getting blocked. Also, my thermostats don't really change that much, so 2 seconds seemed a bit aggressive. I'm going to be looking for an 'active' refresh if an action is taken from the UI, but a passive refresh with much higher latency (this is currently not done).
  • Optional support for "Hot Water". My system does not have a hot water system so the current component was failing. I am making this into an optional section based on a parameter.

Again, as you can see there are quite a few changes that I'm proposing. Happy to discuss them further and/or open a PR if you would like.

[ek5932]

Hey, thanks for the post. Please open a PR and I'll test your changes against my setup. Most of what I have working was based on some other examples I found on the net which was looking at specific nodes to interpret the devices statuses. It worked fine with my setup but when I extended the code to support hot water I noticed that the node values wouldn't always be the same, so I'm not entirely surprised it didn't work without some tweaking.

As for the run modes, I only really left in what I needed (I only use Low, High & Away) as I didn't think anyone else would actually use what I had done but I'm happy to reintroduce all the available options.

I never really used the Away/Party functionality in the JG app itself so I'm not entirely sure how they function but I essentially use Away as a status in HA to track which thermostats are scheduled to be on when I'm not in the house. It simplifies the state management, so for example in the morning if a thermostat is scheduled to turn on but no one is in the house it will go into an Away state. If I then come back home, rather then trying to be smart about which thermostats are scheduled to be turned on now I have returned, I set everything which currently has an Away status to High.

On a final note, the high refresh rates were due to an earlier iteration of the code not updating the mode/temperatures in HA after making changes. I originally thought I was doing something wrong in HA but managed to fix the bug in the JG client code now so it's reliable, so having a configurable interval makes sense. Again, I didn't actually think anyone would actually use this :)

I look forward to seeing the changes in your PR. If anything, me adding this was in hope of someone else contributing to make it better!