Door sensor not reporting to HA

[Liam-Whiteside]

I've got a neohub v2 (firmware v2211) connected to HA using integration 0.2.4. It's got 4 neoStat V2 connected (one for hot water), a couple of air temperature sensors (that I find very intermittent anyway) and a window / door contact sensor.

The window/door contact sensor appears to have stopped reporting to HA, even though it shows the state correctly in the heatmiser app. The device is visible in HA and the entity shows status=off, offline=false, standby=false.

This definitely was working in the past, however it's only now that the door is left open when automations run that it's become obvious there's a problem.

I haven't seen this as a known issue with recent versions, but also can't work out how to get any more debug information to help understand the issue.

[Liam-Whiteside]

I've now found this in the debug, which suggests the API is reporting window_open=true correctly but it's not being converted into the correct entity open event for HA (BTW it would be great if this could be a 'cover' rather than a switch without having to add a helper)

 NeoStat(_logger=<HassLogger neohub (WARNING)>, _data_=namespace(ACTIVE_LEVEL=0, ACTIVE_PROFILE=0, ACTUAL_TEMP='0.0', AVAILABLE_MODES=['heat'],
 AWAY=False, COOL_MODE=False, COOL_ON=False, COOL_TEMP=0, CURRENT_FLOOR_TEMPERATURE=0, DATE='sunday', DEVICE_ID=6, FAN_CONTROL='Automatic', FAN_SPEED='Off', FLOOR_LIMIT=False, HC_MODE='VENT', HEAT_MODE=True, HEAT_ON=False, HOLD_COOL=0, HOLD_OFF=True, HOLD_ON=False, HOLD_TEMP=0, HOLD_TIME='0: 00', HOLIDAY=False, LOCK=False, LOW_BATTERY=False, MANUAL_OFF=True, MODELOCK=False, MODULATION_LEVEL=0, OFFLINE=False, PIN_NUMBER='0000', PREHEAT_ACTIVE=False, PRG_TEMP=0, PRG_TIMER=False, RECENT_TEMPS=['0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', None, None, None, None, None, None, None, '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0', '0.0'],
 RELATIVE_HUMIDITY=0, SET_TEMP='0.0', STANDBY=False, SWITCH_DELAY_LEFT='0: 00', TEMPORARY_SET_FLAG=False, TIME='0: 00', TIMECLOCK=True, TIMER_ON=False, WINDOW_OPEN=True, WRITE_COUNT=0, ZONE_NAME='Patio Door'), _hub=<neohubapi.neohub.NeoHub object at 0x7041395d5220>, _simple_attrs=('active_level', 'active_profile', 'available_modes', 'away', 'cool_on', 'cool_temp', 'current_floor_temperature', 'date', 'device_id', 'fan_control', 'fan_speed', 'floor_limit', 'hc_mode', 'heat_mode', 'heat_on', 'hold_cool', 'fan_control', 'fan_speed', 'hc_mode', 'heat_mode', 'heat_on', 'hold_cool', 'hold_off', 'hold_on', 'hold_temp', 'hold_time', 'holiday', 'lock', 'low_battery', 'manual_off', 'modelock', 'modulation_level', 'offline', 'pin_number', 'preheat_active', 'prg_temp', 'prg_timer', 'standby', 'switch_delay_left', 'temporary_set_flag', 'time', 'timer_on', 'window_open', 'write_count'), active_level=0, active_profile=0, available_modes=['heat'],
 away=False, cool_on=False, cool_temp=0, current_floor_temperature=0, date='sunday', device_id=6, fan_control='Automatic', fan_speed='Off', floor_limit=False, hc_mode='VENT', heat_mode=True, heat_on=False, hold_cool=0, hold_off=True, hold_on=False, hold_temp=0, hold_time=datetime.timedelta(0), holiday=False, lock=False, low_battery=False, manual_off=True, modelock=False, modulation_level=0, offline=False, pin_number=0, preheat_active=False, prg_temp=0, prg_timer=False, standby=False, switch_delay_left=datetime.timedelta(0), temporary_set_flag=False, time=datetime.timedelta(0), timer_on=False, window_open=True, write_count=0, name='Patio Door', target_temperature='0.0', temperature='0.0', weekday=<Weekday.SUNDAY: 'sunday'>), 

[MindrustUK]

Hi @Liam-Whiteside ,

Try the Dev branch and see how you get on. I'm avoiding doing anything on master and trying to focus any time I get on Dev which will eventually replace it.

Converting the Sensor from a switch to a cover seems a good idea, it's a better fit as these sensors are usually on doors or windows. I'll add that to my todo list.

[Liam-Whiteside]

Ok, I'll give that a try. It doesn't look like you can just go into HACS, select re-download and enable the "beta" version, which would also be nice to implement.

Part of my thought about making it a "cover" was if it could also be read only, as trying to switch a sensor from the UI doesn't really make sense.

[Liam-Whiteside]

That's now working again, however (having deleted the integration and re-adding) the contact sensor got labelled "sensor.patio_door_heatmiser_contact_sensor_contact_sensor" with on=open and off=closed

I tried to create a "Change device type of a switch" helper to convert it to a different type (as I'd done before) so the states became open and closed, however I now get this error when trying to create the helper
Entity sensor.patio_door_heatmiser_contact_sensor_contact_sensor belongs to domain sensor, expected [<Platform.SWITCH: 'switch'>]

So it looks like you've already got it as a read only device rather than a switch, but it would be nice if the states could be open and closed.

The hot water no longer being an obvious on/off switch also confused me, I assume "switch.hot_water_heatmiser_neostat_v2_timer_hold" is the one to use to see when it's on and override? I'm not sure what "switch.hot_water_heatmiser_neostat_v2_hold_state" is supposed to do.

[ceee5]

@Liam-Whiteside try Timer Output Active for your hot water

Mindrust kindly implemented for me in this thread

#153

[MindrustUK]

Hi @Liam-Whiteside I've had a look into converting the sensor to cover, on the surface of things while this may look the way to go after some investigation it's not really sensible to do so. Covers are things like gates, awnings, curtains etc and are expected to be controllable. Ie writeable. The magnetic sensors are just this, sensors. They are read only devices best fitted to this class. I'm going to reject your request to change the device type based on this.

On changing the state to open or closed, this makes some sense but requirements change per implementation. I.e. in one case it maybe a window, in another a door. The most universal way is to keep this as a boolean on / off sensor.

Please see documentation here: https://developers.home-assistant.io/docs/core/entity/binary-sensor

Based on this there maybe scope for a future feature request to make these configurable per application. That is to say options could be investigated to re-map the class via configuration options. One I may look at in the future but it's going to be on a lower priority. I'll leave the ticket open to remind me to add a feature request for this at a later date.

[ocrease]

As @MindrustUK has mentioned this should not be converted to a cover since that is for things that can be controlled. The reason the state is shown as On/Off rather than Open/Closed is because when the binary sensors were added to the integration, they were added as a sensor rather than a binary_sensor. You can see that the name is "sensor.patio_door_heatmiser_contact_sensor_contact_sensor".

As part of #201 I moved the binary sensors to be set up in the correct platform (eg binary sensors.py) so they will correctly display the state based on the device class, eg Open/Closed rather than On/Off

[ocrease]

@Liam-Whiteside I think the issues you had with the state reporting of the contact sensors should be resolved in the dev branch.

[Liam-Whiteside]

This version is looking a lot better. Thanks

I can now install the dev version from the UI, it gives a human readable version number, the controls for hot water are there, and the contact sensor looks like it's behaving better.

[Liam-Whiteside]

A minor detail, is it possible to make the sensor.hot_water_hold_time_remaining value display without seconds, as it only has whole minutes available, 0:30:00 changes to 0:29:00 etc. This may be a limitation of HA.
Currently there isn't a way to set that hold time, which you can do in the Heatmieser app (however I'm unlikely to use that feature)

[ocrease]

@Liam-Whiteside to set a custom duration you have to use the Timer Hold On service provided by the integration.

Regarding the display of the hold time remaining, that's really a display issue and other features in HA to display it how you want. Some people might want 0:27, others might want 27 Minutes or 27 Min etc... The reason it is displayed as 0:00:00 is because the underlying value is a Python timedelta object and that is the standard string representation. In a jinja template you could use the as_timedelta filter to convert it back to a timedelta.

One example for stripping the seconds for display would be {{ states('sensor.hot_water_hold_time_remaining')[:-3] }}which would get rid of the last 3 characters in the string.

[Liam-Whiteside]

As the value is a string, not a datetime, I created a template helper and used this
{{ strptime(states('sensor.hot_water_hold_time_remaining'),'%H:%M:%S')|as_timestamp|timestamp_custom("%M") }}

[ocrease]

@Liam-Whiteside that probably won't work if the remaining duration is over an hour:

If you just want it in minutes, I would recommend the alternative:

{{ ((states('sensor.hot_water_hold_time_remaining')|as_timedelta).total_seconds()/60) | int }}

Note that the value is a timedelta, not a datetime. The return value of the states function is always a string though which is why you have to use the filter (| as_timedelta) to convert it.

[ocrease]

@MindrustUK probably another one that can be closed?

[MindrustUK]

Agreed. Closing.

[ocrease]

@Liam-Whiteside I'm proposing to change the duration sensor. Please see #214

[Liam-Whiteside]

I think that's sensible. Potentially more useful than having to convert from a string before adjusting the display.