Thank you for the clear explanation. Makes sense now. They could have named them better or put that description in the app to save the confusion. 
I updated the code for changing the Thermostat Card colours again to be different colours dependent on whether Passive Manual or Passive Follow Schedule is selected.
Iām reposting instead of changing the original in case anyone wants to use the original code and just have one colour for both.
I have also amended the if statements, so that if the displayed names of Passive Mode change, it will still work.
type: thermostat
entity: climate.garage_climate
name: Garage
card_mod:
style: >-
{%- if 'Passive' in state_attr(config.entity, 'preset_mode') and is_state(config.entity, 'heat') -%}
ha-card {
--state-climate-heat-color: var(--state-binary-sensor-color) !important;
}
round-slider {
--round-slider-bar-color: var(--state-binary-sensor-color) !important;
}
{%- elif 'Passive' in state_attr(config.entity, 'preset_mode') and is_state(config.entity, 'auto') -%}
ha-card {
--state-climate-auto-color: #8BC34A !important;
}
round-slider {
--round-slider-bar-color: #8BC34A !important;
}
{%- elif is_state(config.entity, 'off') -%}
round-slider {
--round-slider-bar-color: var(--state-climate-idle-color) !important;
}
{%- endif -%}
Hopefully this will be of use to someone. 
@msp1974 Given itās possible to change the colours, which makes it really easy to see which of the two Passive Modes is being used, I think there is even less need to display āPassive(M)ā and āPassive(FS)ā and instead just use āPassiveā. I know itās only a few characters saved, but it might stop the text size shrinking as much when āHeating - Passiveā is displayed. Just my thoughts, as always.
1 Like
Sorry - been away for a few days enjoying the Paris riots!
Anyway, this is great but you can massively simplify and should still work. This will give lighter colours for HVAC mode if in passive mode. I will add an is_passive attribute for release that will make the if statement simpler still.
type: thermostat
entity: climate.garage_climate
name: Garage
card_mod:
style: |-
{%- if state_attr(config.entity, 'preset_mode') in ['Passive(M)','Passive(FS)'] -%}
ha-card {
--state-climate-heat-color: var(--amber-color);
--state-climate-auto-color: var(--light-green-color);
}
{%- endif -%}
1 Like
This is much simpler than what I had 
and produces the same result.
@msp1974 Iāve noticed a couple of other things regarding Passive Mode in the latest beta. I suspect these are not new things, but have either been in there since the start in the case of the second point, or introduced with Passive Follow Schedule in the case of the first point. The more complex this becomes, the more things need to be accounted for I guess.
There may not be anything that can be done about them, but I thought it worth mentioning even if itās to only add it to the wiki/documentation if they are just a byproduct of how this works. I do have a workaround of sorts for the first point, which I will also detail.
Yesterday I set my Hallway to Passive Follow Schedule with 1 degree between the max and min, thinking it could maybe save a bit of energy doing so, as itās quite often the only room calling for heat. This morning it was colder than I expected i.e. below the minimum and maximum temperature (which were both at 16 degrees). It took a few minutes to realise, but the reason was because it doesnāt follow Comfort Mode settings when in Passive Follow Schedule. My schedule is set to be at temperature by 09:00. The rest of the main rooms were heating and had been for a while by 08:00, but the Hallway was still at the nighttime setback temperature of 16 degrees (and wouldnāt change until 09:00 when the schedule changes) and was not heating because it doesnāt take into account Comfort Mode that is in operation in all the other rooms to make sure itās at the target temperature by 09:00.
Itās not perfect, but to partially work around this, what I have done is create a Schedule Helper, which I have set to the same schedule as the main rooms, of which the Hallyway is part of. I have then created an automaton that will swtich Passive Mode on at the beginning of the schedule and off at the end of the schedule. Therfore, because Passive Mode will be off before 09:00 it should (I have still to test this) allow Comfort Mode to bring the heating on early, as it would have done previously, before the automation switches to Passive Mode at the beginning of the scheduled target temperature change at 09:00. It will then switch off at then end of the schedule i.e. overnight. So, in a nutshell, I have scheduled Passive Mode to turn on and off using an automation and using a Schedule Helper to set the times. I donāt know whether this is something that can be built into the integration, or rather than creating a Schedule Helper, if itās possible to access the Wiser schedule times directly?
The other thing I noticed, and this is a consequence of creating the above automation, as I was thinking whether I needed any conditions and wondered what would happen if Away Mode was switched on. Well, itās fine to switch Away Mode on while Passive Mode is enabled (I assume this is because the Away Mode setpoint is below any of the min values), but if you swich Away Mode off while Passive Mode is enabled, it will revert to the higher temperature of the schedule and not what is set in Passive Mode. Consequenly, I have a condition of Away Mode being off in my automation.
I hope this all makes sense and itās a good reason for it to be in beta I guess, so we can find these little quirks.
P.S. Sorry if I am creating more work for you.
This is probably really basic, but I canāt seem to find the answer anywhere so just thought Iād throw it out here: is there a way to display just the current temperature from an iTRV or RoomStat in order to display it on a dashboard? Iād like to be able to add current room temperatures to a floor plan for display alongside other things (lights on, etc) but simply canāt seem to find a way to get that displayed at all, let alone as a neat little icon like other temperature sensors have
Many thanks to anyone that can help!
Yes, if you have LTS (Long Term Statistics) sensors switched on in the integration configuration, there will be a sensor.room_name_temperature_lts or similar entity available (I have renamed my entities from the defaults, so canāt tell you the exact naming convention used).
Else, you can template out (create a template entity for) the current_temperature attribute of the climate entity for each room.
Or, you can just use the current_temperature attribute directly in your dashboard.
Probably the easiest thing to do though, is switch on the LTS sensors in the integration configuration if they are not already enabled. IIRC @msp1974 has enabled these by default in the latest beta, which will feed through into the main releases in due course.
1 Like
I didnāt have the LTS sensors enabled, thatās what was missing! I knew it was going to be something relatively straight forward, thanks!
LTS donāt provide current_schedule_temp so I have below to show scheduled temperatures in single row
type: horizontal-stack
cards:
- type: entity
entity: climate.wiser_living_room
icon: ' '
unit: Ā°C
attribute: current_schedule_temp
name: ' '
- type: entity
entity: climate.wiser_spare_room
icon: ' '
unit: Ā°C
attribute: current_schedule_temp
name: ' '
1 Like
Now we are at the stage of ironing out the last few bugs, do we know if the passive mode works with the room display controller please with multiple radiators / iTRVās?
I have a room with a display unit for the control setpoint and one radiator with an iTRV.
I assume passive mode can be set somehow in this configuration.
(By āweā, I of course mean you guysā¦ Fantastic job in implementing passive mode). 
I think comfort mode is not actually āpassiveā ie it will call for heat ahead of the schedule. I get that in reality it is setting the target temp ahead of the schedule time to do this but it actually isnt setting the target temp but doing things on the hub to achieve this. Why donāt you just set the schedule earlier as it will only heat when others are calling for heat? Ie set it to be at temperature from 6am and then it will heat as the other āactiveā rooms are getting up to temp?
I did have away mode on my list to look at but I think your description is also one of the main problems with away mode on the hub in that any changes to the temp (overrides etc) or change of mode takes that room out of away mode (irrespective of passive mode). As we are using overrides to stop calling for heat when in passive mode, this will always knock the room out of away mode.
In terms of turning away mode off when in passive mode, yes, it will immediately go back to the upper temp for the schedule but then the automation code will knock it back down. However, it kind of needs another update cycle to actually show this and the hub updates to get the current readings, the automation runs and sets the temp the room should be at for passive but then this is not re-read until the next update cycle.
I will have a think about this to see if it make sense to re-read the hub if the pasisve mode code has made changes.
Yes this should work. As trvs and roomstats are just devices in a room and the passive mode actually controls the room, then I donāt see this should make too much difference. The only possible thing is what the roomstat displays. I will have a play with this but likely it will show the āpassive modeā temp ie min temp when no active rooms heating and incremented temps upto max/scheduled temp when rooms are heating. This may look a bit odd granted.
I did think about putting the Hallway on itās own schedule with an earlier start time. I guess that is another workaround/solution. I was really trying to keep it in the main schedule rather than fork it off onto itās own though. I suspect what I have done will be fine as a workaround.
Neither of these is a big deal really and a small price to pay for having emulated Passive heating. I really just thought it was worth pointing out, as it probably ought to be documented as a ālimitation/quirkā if nothing else.
Same with Away Mode. Again, really just documenting what I am observing in case itās useful if for nothing more than documenting it.
It will do exactly that. I can see it in the template sensors I created for the Displayed Setpoint, in the Wiser app and on the room thermostats. I have room thermostats and multiple iTRVs in a couple of rooms and have had no issues that I have noticed.
Maybe there should be an option to prevent Passive Mode being enabled/disabled when Away mode is on?
Iām potentially thinking that I should create an automation to disable Passive Mode in all rooms when Away mode is activated and re-enable it when deactivated. Could store the rooms it was active in, in Helpers.
Something I havenāt tested is what happens when Away Mode is on for 24 hours and how it reacts to changes in target temperature if Follow Schedule is selected.
I donāt like the idea of going on holiday for two weeks thinking Away Mode is on, but that Passive Mode has knocked the temperatures up. I know I can check it remotely, but I think I/we should try and test this somehow.
Having thought more about this, I think you are right - but not for the right reason! 
Given you can see it is in auto or heat mode, just the passive flag is probably enough (with good explanaition in documentation - oh my favorite!).
1 Like
I had mentioned the fact you could see the icon selected previously (i.e. Auto vs Heat), which sort of made it redundant. It was also the reason I suggested changing the label to Passive(A) as in Auto, as thatās the icon that is selected when Follow Schedule is active. The fact the colours can be changed too, really just makes the need for it even less IMO.
@msp1974 I guess, in theory, it should be possible to test the effect of 24 hours in Away Mode with Passive Mode enabled by setting the Away Mode Target Temperature just below that of the Scheduled Target Temperature? Really just trying to think of a way of testing this without having a cold house or actually being away for 24 hours.
Iām happy to help with documentation if you want.
I have been lucky not to have the severe wifi outages that many see/have seen, but my system is not happy. It pretty much works as far as using it is concerned (I very occasionally see entities unavailable for a minute or so), and I have a ping sensor running which never seems to report the hub as down, but I see errors in the logs all the time like this, do others see this kind of thing? (latest firmware and integration):
Logger: custom_components.wiser.coordinator
Source: helpers/update_coordinator.py:182
Integration: Drayton Wiser Integration for Home Assistant (documentation, issues)
First occurred: 21 March 2023 at 11:59:37 (49 occurrences)
Last logged: 14:27:16
Error requesting wiser (wiser-WiserHeatxxxxxx) data: [Errno 104] Connection reset by peer
Error requesting wiser (wiser-WiserHeatxxxxxx) data: Server disconnected
Error requesting wiser (wiser-WiserHeatxxxxxx) data: Response payload is not completed
----------------------------
Logger: custom_components.wiser.coordinator
Source: custom_components/wiser/coordinator.py:141
Integration: Drayton Wiser Integration for Home Assistant (documentation, issues)
First occurred: 21 March 2023 at 11:47:22 (53 occurrences)
Last logged: 14:27:16
Response payload is not completed
[Errno 104] Connection reset by peer
Server disconnected
-----------------------------
Logger: custom_components.wiser.coordinator
Source: custom_components/wiser/coordinator.py:138
Integration: Drayton Wiser Integration for Home Assistant (documentation, issues)
First occurred: 21 March 2023 at 11:46:41 (29 occurrences)
Last logged: 14:24:54
Connection timeout trying to communicate with Wiser Hub 192.168.1.129 for url http://192.168.1.129:80/data/v2/domain/
Connection timeout trying to communicate with Wiser Hub 192.168.1.129 for url http://192.168.1.129:80/data/v2/schedules/
Connection timeout trying to communicate with Wiser Hub 192.168.1.129 for url http://192.168.1.129:80/data/v2/network/