I get this as part of the menu when I added the T6 to HA Green. What does this mean?
AC mains disconnected.
It means it is running on battery only. Likely because you joined the zwave network while it was not connected to the mount therefore powered by mains.
Remove the device from the zwave network. Make sure it is mounted and powered then reconnect it to the zwave network.
I removed it and added back, and it came back and it’s only on 24v. It’s a different issue and Honeywell says this dashboard entity is not in their database.
AC mains disconnected
binary_sensor.t6_pro_z_wave_programmable_thermostat_with_smartstart_ac_mains_disconnected
I have that sensor on my T6 it is off because I have it powered by 24vac. Recheck your wiring.
Yours says it’s off and it’s connected to 24v AC? Mine says plugged in. I just don’t understand the sensor.
My sensor is ac mains disconnected.
Anyways, your sensor indicates that your device has 24vac power. If you turn the 24vac off (usually by turning the furnace emergency switch off) then it should report the device does not have power.
Can anyone explain why there’s two entities with the same command class:
âžś .storage jq '.data.entities[]|select(.unique_id | test("43-113-0-Power Management-Mains"))|{original_name,entity_id,unique_id}' core.entity_registry
{
"original_name": "AC mains disconnected",
"entity_id": "binary_sensor.hall_thermostat_ac_mains_disconnected",
"unique_id": "3524181575.43-113-0-Power Management-Mains status.2"
}
{
"original_name": "AC mains re-connected",
"entity_id": "binary_sensor.hall_thermostat_ac_mains_re_connected",
"unique_id": "3524181575.43-113-0-Power Management-Mains status.3"
}
It’s a bug. Not because they are have the same command class, but because they are the same notification state variable that is a binary state.
Maybe I used the wrong wording. Isn’t it that when the device updates that specific state that two entities are updated?
Does the integration map the update from zwave-js via the unique_id of the entity? And what are those trailing .2 and .3 values?
Maybe I used the wrong wording. Isn’t it that when the device updates that specific state that two entities are updated?
The Command Class here is Notification CC. There is not an exclusive one-to-one relationship between a command class and an entity. A command class can support many different features (thus entities). The Notification CC allows for hundreds of possible entities.
The unique ID is generated from several properties of a Value ID, and it differs based on the platform. When the entity is setup HA is just listening for value updated events for the corresponding Value ID.
And what are those trailing
.2and.3values?
.2 and .3 are the Z-Wave JS Value ID “state keys” for the “Mains status” notification state variable (defined in the spec here). They are the actual notification event values received from a device and Z-Wave JS maps that to a string description. For binary notification-based entities they are appended to the unique ID.
There is a bug (regression) that was introduced some time in the summer (I haven’t had time to write up a proper bug report) and states that are intended to be skipped are still generating entities.
E.g. these “idle” sensors (idle state 0) that were created for a smoke alarm should not exist.
Or these duplicate “Door is closed” entities that are the binary opposite of the normal “is open” sensors. This is the same scenario as the mains status one.
But, this is getting somewhat off topic. In the case of this thermostat, the “AC mains re-connected” entity with the proper device class is the expected entity, while the “AC mains disconnected” entity without a device class is the incorrect entity.
1 Like
Honeywell T6 Pro TH6320ZW2007 Issue #160029
The owner closed it because I didn’t present the information properly.