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

https://github.com/MindrustUK/Heatmiser-for-home-assistant/issues/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.