Propose several changes
bouwew opened this issue · comments
In my testing, I replaced HEAT_MODE_OFF by HEAT_MODE_HEAT.
This results in the following:
And:
From my point-of-view, this makes the functionality shown in the Lovelave Thermostat-Card more clear: the calendar-icon represents that a schedule is active, the heating-represents that a temperature-setting or a temperature-preset is active.
To do: when the schedule is active, show the active schedule-name instead of the preset-name.
If we make it clear enough from README/documentation point of view this is a good approach IMHO!
Below part is more to ensure were on the same page (sharpening the idea of the todo:)
Sidenote (more from device-point-of-view) scheduling only tells you about when it switches to either a predefined temperature (by number) or a preset.
I don't think the frontend card has something where you can indicate the schedule name (yeah, we could where it says home/idle/away, but that really is about the presets, right). Playing around with the device itself I'm not able to 'not' select a preset either.
From user perspective, if (for whatever reason) we temporarily override (which you can, even with schedule active), how would we envision that displayed?
I am trying to abuse the preset state on the card for that:
@property
def preset_mode(self):
"""Return the active preset mode."""
if self._hvac_mode == HVAC_MODE_AUTO:
return self._active_schema
return self._api.get_current_preset(self._domain_objects)
But then the preset state is lost when switching to the schedule.
On your Sidenote, you are correct, the frontend card can only show the hvac_action and the preset_mode. With that in mind, I tried the above trick, with the negative effect of losing the preset_state on the Anna but not in HA.
And, you have a point there: the possibility to deactivate the presets is missing. But that should not be too difficult to fix?
And-2, we could show "Temporary" as the preset-name when the User overrides the preset or the schema.
I'll have a look into the XML if we can do something with dates then ... that might work (like if preset_set > last_schedule_induced_change if there is such a thing).
The 'HVAC_MODE_HEAT' is more obvious than using 'HVAC_MODE_HEAT_COOL' (i.e. the color changes) - not sure if you tried that, it gives you the 'recyling'-icon and the graph stays green. So going with the heat as you indicate might be the better option.
deactivating the presets
Not sure it that's even a thing on Anna :) Lets try!
Ah it is, Just the mobile app still keeps showing the preset. I see possibilities, now to look into the xml (tonight)
Yes, that can be done, via long-press on the top area, can need several long presses.
I'll play a bit more with the code, until I have to spend time on other subjects (wife, F1 race).
I'll put the result on my github: https://github.com/bouwew/anna-ha
Long-press was only schedule on/off, right? Does it also turn down preset? Just hitting - or + does remove the preset (although the app doesn't show it).
With long-press I mean pressing onto the top-bit of the Anna hardware.
When both a schedule and a preset are active, a short touch changes the preset, a next long-press removes the schedule, the next long-press removes the preset and reactivate the schedule. And so on. So, yes, long-press activates and deactivates the schedule.
And a short press activates a preset. Deactivating a preset can only be done by a long-press which activates automatically a schedule.
I never tried a long-press in HA.
Roger that, I should RTFM, I never short-pressed it :)
In that case we definitely should be able to add 'schedule' or even it's active name to the home/away/etc. list. I'll diff the XMLs tonight as promised.
States: (there is a question on that last one!)
- On schedule (determined by schedule active, schedule last time newer than preset) = show name of schedule
- On preset (determined by preset last time newer than schedule active) = show name of preset
- Clicking schedule icon = always go back to last active schedule (or remain on active schedule)
- Clicking heating icon = just disable schedule
And there is no long-press in HA, I did mean the hardware :)
On States, yes, my updated code does exactly all this. Plus showing "Temporary" when the temp is changed manually via the arrow-up or -down buttons.
And indeed, clicking the heating icon disables the schedule. And it does NOT activate a preset, this has to be done with an extra action (selecting a preset). I was hoping that the last active preset would become active, but that does not happen, this behavior is in line with what happens when manipulating the Anna-hardware.
I was testing a bit more just now, I noticed that when in Auto-mode, the text "Temporary" is only shown until the next interval-update is executed.
We would need a function that detects that the target-temperature changes due to a change in schedule or preset and then change self._manual_temp_change to false.
We can fix that temporary stuff, you'll just have to work around a bit, let me see if I can write something up. The approach is ok, but it needs a bit more tinkering in other functions. (Basically you'll need to delay the 'set it to false' again).
The part that I was looking for is there indeed, it's just in another XML location http://SMILE_IP/core/appliances - see 3rd line from the bottom, where it says none this was due to a long-press (on hw) disable of schedule. It says home when activating things again. We probably need this in some degree as /core/domain_objects at that point still indicates it's home (which is what get_current_preset of haanna.py looks for now.
<point_log id="...">
<updated_date>2019-08-04T20:44:58.690+02:00</updated_date>
<type>preset_state</type>
<unit/>
<last_consecutive_log_date>2019-08-04T20:44:58.690+02:00</last_consecutive_log_date>
<preset_state id="..."/>
<period start_date="2019-08-04T20:44:58.690+02:00" end_date="2019-08-04T20:44:58.690+02:00">
<measurement log_date="2019-08-04T20:44:58.690+02:00">none</measurement>
</period>
</point_log>
Unfinished - as in the 'none' detection should still go somewhere, but just assuming you're looking for something like this? https://github.com/laetificat/anna-ha/compare/master...CoMPaTech:issue19?expand=1
BTW, I stand corrected, you are totally right (wrt HVAC_MODE_HEAT):
https://developers.home-assistant.io/docs/en/next/entity_climate.html#docsNav
The device is set to heat to a target temperature.
So presets is a wildcard we can use, but preparing all possible {preset}@{schedule} is as much hard work (determining which presets are availabe in a schedule) as making a long list dat isn't UX-friendly.
On showing "Temporary", I was having the same idea :)
But my programming skills are not that great to come up with a solution.
My main thought is: is there something in an XML that could be used?
On your proposal-code, sorry, I don't like it, too much information :)
My opinion: I would like to see the activity of the CV-heater (Idle or Heating) and the active automation (either a schedule or a preset), or nothing when no automation or preset is active.
While testing your code, it shows Idle - Home @ Weekschema, but on the Anna only the schedule-icon is shown and not the Home-icon, so the information shown is not correct.
Finally, I noticed the "append(None)" bit. This adds a blank entry in the preset-list, when pressing it, HA show a failure-message.
Update: I copied some of your code-changes into my github.
Also, I fixed the issue that a preset-state is shown on the card when no preset is set. Which happens when you disable the schedule by pressing the heating-icon.
Update 2: I was playing around with the Plugwise App and using the HA interface. I see one difference; on the App I can set a preset that overrides the active schedule temporarily. This cannot be done via the HA interface. I can see the call "Changing preset mode" in the HA log but nothing happens on the Anna. So, I guess there's a bug in Haanna?
While I write this, I'm thinking, how to show this on the card? My idea: schedule-icon = green and show the selected preset instead of the selected schedule until the schedule take the control again. Similar to showing Temporary, as discussed above.
I still have to look at your fork, apologies. On the bug, I can set the schedule on mine (shows in the app and on the hardware)?
The idea you posed looks good, we should be able to make that work (schedulename if that is on, if overridden show preset).
Hi Tom, no problem, real life has priority over this stuff :) Same is valid for me these days...
On the bug, I can set the schedule too. But when I try to activate an additional preset in HA, with the schedule active, nothing happens on the Anna (only the schedule-icon is visible, no preset-icon appears on the Anna).
While on the Anna, you can activate a preset (as a result both the schedule- and preset-icons are shown, with the selected preset overriding the schedule until the next schedule-change.
I did some more testing/playing around today.
I again noticed the issue that plugwise-dev keeps reporting a preset when no preset is shown on the screen of the Anna. Should this be solved in haanna? I mean, plugwise-dev reports what comes back from the haanna-call, correct?
Not able to make time yet, but it indeed feeds off of self._api.get_current_preset(self._domain_objects) run through haanna.
It's specifically just looking up http://{ip}/core/domain_objects' and then the location part. (see screenshot). If you have your Anna in no_preset` mode, what does it show in the XML?
I'm guessing deleted_date will be updated and we should modify haanna to return None when it is :)
Mine looks like this (I think):
<location id="7016f24013f34f23b71c4d14af5beff0">
<name>Living room</name>
<description>The room containing the (central) home thermostat.</description>
<type>livingroom</type>
<created_date>2019-07-06T12:15:13.354+02:00</created_date>
<modified_date>2019-08-18T13:15:55.711+02:00</modified_date>
<deleted_date/>
<preset>home</preset>
This is after I turned on the weekly schedule, Anna shows only the schedule-icon.
I first tried with the preset Away, then preset Home, then activated the weekly schedule.
See above for the end-result. First it showed away as preset, then home, then still home.
I guess there is no way to find that no preset is selected, or we are looking at the wrong spot?
Best to solve this in the plugwise-dev code: when the schedule becomes active, set self._preset_mode to None.
Then we should alter the 'get_preset' and it should also reply none (hence, it should check if schedule is active THEN always return none) ... feels fidgety
(as in ... get_preset is called through the loop afair)
Never mind, I found the correct spot!
<point_log id="c5ccff202c824a2fb5f2d19fed80a3d1">
<updated_date>2019-08-18T13:45:29.533+02:00</updated_date>
<type>preset_state</type>
<unit/>
<last_consecutive_log_date>2019-08-18T13:45:29.533+02:00</last_consecutive_log_date>
<preset_state id="cc51e92a98b047eab63eb0f831c65bfe"/>
<period start_date="2019-08-18T13:45:29.533+02:00" end_date="2019-08-18T13:45:29.533+02:00">
<measurement log_date="2019-08-18T13:45:29.533+02:00">none</measurement>
</period>
</point_log>
I did the same thing: first set preset to away then to home and then I activated the schedule, with none as the end-result!
Some lines up there is also a schedule_state showing the measurements on or off. Also quite useful :)
And also a domestic_hot_water_state which shows the measurement on when hot water is being tapped. Answering a previous question from you :)
Great work, definitely something for haanna 12 to get started on. I'll have a look this weekend, tnx!
Still need to find some time, sorry
When you have time, check out: https://github.com/bouwew/haanna
I just implemented all the changes we discussed above. I also added the possibility of getting the domestic_hot_water_status.
Actually easier than I thought :)
All changes have been tested in IDLE. Next, testing in HA.
Cool, will do! (Great job)
it works in HA too:
I temporary adapted my code a bit, to be able to show this status.
I also tried to find a way to show the DHW-status. I can find one good reference in HA:
/components/stiebel_eltron/climate.py:
Mapping STIEBEL ELTRON states to homeassistant states/preset.
STE_TO_HA_HVAC = {
"AUTOMATIC": HVAC_MODE_AUTO,
"MANUAL MODE": HVAC_MODE_HEAT,
"STANDBY": HVAC_MODE_AUTO,
"DAY MODE": HVAC_MODE_AUTO,
"SETBACK MODE": HVAC_MODE_AUTO,
"DHW": HVAC_MODE_OFF,
"EMERGENCY OPERATION": HVAC_MODE_AUTO,
}
Also interesting how in this code HA-states are mapped to device-states...
I have one more change: change the name active_schema to selected_schema.
An active_schema can be selected but off, so using "selected" makes more sense to me :)
@CoMPaTech, please see my anna-ha github:
- selected_schema change
- CURRENT_HVAC_DHW and detection as hvac_action added
- returned preset_mode to only showing the preset_state, for the purpose of testing
Quickly tested in my HA system. More testing later.
Sharing some observations:
- Activating a preset overrides a manual temperature setting indefinitely, or, it overrides the schedule-temperature until the next schedule-change, this is as expected.
- But, a manual temperature change on the Anna disables an active preset, in both the situations that a schedule is active, and no schedule is active, this was unexpected, but good to know!
@CoMPaTech, please see my anna-ha github for more updates.
As far as my testing goes, it all seems to work as I want it to:
- on the climate-card the activity of my boiler is show (idle, heating or dhw), next to the selected schedule or the selected preset or "Temporary" (only when a schedule is active).
- from the active icon it is clear whether it's on Auto (a schedule is active) or Heating (a preset is active or the temperature-setting is a left-over from a previously active schedule or preset, or comes from a manual temperature change).
Agreeing with all changes as already commented on the community platform, we probably need the older Anna firmware confirmation and fix the 'non-boiler' issue, but other than that I'd say nice coding! Even though we need the confirmation I'd say start up a PR against here and let's fix it, maybe it's an idea to add you as author/contributor too (@laetificat how'd you feel about that - both haanna and anna-ha?).
Thanks! W.r.t. my coding, I'm very much an amateur but I seem to be getting the hang of it on the detailed level. Still much to learn on the "higher levels".
I could create the PR's, already started to do that for haanna. Could we follow a similar review-process like practised on the HA github? That is probably a function of Github? Is this process documented somewhere?
Also, I was thinking to create an Issue on the Home Assistant github, requesting adding the CURRENT_HVAC_DHW mode to the HA Climate component, with a fitting icon on the Climate-card :)
It's inherently the way github works, if you create the PR it will show up in these repo's. (https://help.github.com/en/articles/creating-a-pull-request). The difference with HA is that it has a lot more CI/CD in place to check for code correctness and stuff, but we can leave that up to when we merge the changes to the HA repo. (It will also do a lot of testing).
Creating an issue is a good option to get an opinion on additional items, mostly HA-ers are very helpful as I found out during upstreaming, but some things might not pass, but we'll here soon enough if that is the case.
To get you going I'll create a PR against your code so you'll see the magic happening (or not) :)
Another observation after one night running with my latest code:
On the Climate card, the state is "idle - asleep". I checked on the Anna, there is no preset-icon shown.
But in the xml /core/domain_objects the preset_state is shown as asleep.
I think this the case because when you set a temperature in a schedule that is equal to a preset-temperature, in the schedule on the App, the temperature-value is replaced by the preset-name. And apparently this preset_state is not cleared when a next, custom, setting becomes active.
As a follow-up to my previous post, I'm thinking, we could compare the schedule_temperature to all of the preset temperatures. When equal, the reported preset must not be active. I will monitor and test some more, to find out whether this idea is useful.
Update: better to compare schedule_temperature, thermostat (temperature) and the preset temperatures. And also check the schedule_state and the preset_state. Based on these inputs it should be possible to find the exact state the Anna thermostat is in.
@CoMPaTech
Ok, got it all working, please see my github. Both haanna and anna-ha/plugwise have been updated.
A pull-request will be issued soon...