Fibaro flood sensor wakes up but HA doesn't notice

Configuration Z-Wave
1

I have two Fibaro flood sensors, both on battery power. One has firmware 3.02 and the other has 3.03. The 3.03 sensor works well AFAICT. The 3.02 sensor also mostly works well, but for some reason HA doesn’t always notice when it wake up according to the logbook. At first I thought it wasn’t waking up, but according to the OZW log it definity is, but HA doesn’t seem to notice most of the time. I’ve only seen HA notice and log the 3.02 as being awake once in the last week.

Here’s the output from the OZW log for a wake-up that HA logged:

2020-01-03 09:44:25.073 Detail, Node014,   Received: 0x01, 0x0a, 0x00, 0x04, 0x00, 0x0e, 0x02, 0x84, 0x07, 0xb1, 0x00, 0xcf
2020-01-03 09:44:25.074 Detail,
2020-01-03 09:44:25.074 Info, Node014, Received Wakeup Notification from node 14
2020-01-03 09:44:25.074 Info, Node014,   Node 14 has been marked as awake
2020-01-03 09:44:25.074 Detail, Node014, Queuing (WakeUp) WakeUpCmd_NoMoreInformation (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x84, 0x08, 0x25, 0xc7, 0x87
2020-01-03 09:44:25.074 Detail, Node014, Notification: Notification - Node Awake
2020-01-03 09:44:25.075 Detail,
2020-01-03 09:44:25.075 Info, Node014, Sending (WakeUp) message (Callback ID=0xc7, Expected Reply=0x13) - WakeUpCmd_NoMoreInformation (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x84, 0x08, 0x25, 0xc7, 0x87
2020-01-03 09:44:25.082 Detail, Node014,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-01-03 09:44:25.083 Detail, Node014,   ZW_SEND_DATA delivered to Z-Wave stack
2020-01-03 09:44:25.196 Detail, Node014,   Received: 0x01, 0x18, 0x00, 0x13, 0xc7, 0x00, 0x00, 0x0b, 0x00, 0xb1, 0x7f, 0x7f, 0x7f, 0x7f, 0x01, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x00, 0x8b
2020-01-03 09:44:25.196 Detail, Node014,   ZW_SEND_DATA Request with callback ID 0xc7 received (expected 0xc7)
2020-01-03 09:44:25.196 Info, Node014, Request RTT 120 Average Request RTT 84
2020-01-03 09:44:25.196 Info, Node014,   Node 14 has been marked as asleep
2020-01-03 09:44:25.196 Detail,   Expected callbackId was received
2020-01-03 09:44:25.196 Detail,   Expected reply was received
2020-01-03 09:44:25.196 Detail,   Message transaction complete
2020-01-03 09:44:25.196 Detail,
2020-01-03 09:44:25.196 Detail, Node014, Removing current message
2020-01-03 09:44:25.196 Detail, Node014, Notification: Notification - Node Asleep

Here a little later the sensor wakes up again but HA misses it:

2020-01-03 10:52:06.486 Detail, Node014,   Received: 0x01, 0x0a, 0x00, 0x04, 0x00, 0x0e, 0x02, 0x84, 0x07, 0xb1, 0x00, 0xcf
2020-01-03 10:52:06.486 Detail,
2020-01-03 10:52:06.486 Info, Node014, Received Wakeup Notification from node 14
2020-01-03 10:52:06.486 Info, Node014,   Node 14 has been marked as awake
2020-01-03 10:52:06.486 Detail, Node014, Queuing (WakeUp) WakeUpCmd_NoMoreInformation (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x84, 0x08, 0x25, 0xc9, 0x89
2020-01-03 10:52:06.486 Detail, Node014, Notification: Notification - Node Awake
2020-01-03 10:52:06.488 Detail,
2020-01-03 10:52:06.488 Info, Node014, Sending (WakeUp) message (Callback ID=0xc9, Expected Reply=0x13) - WakeUpCmd_NoMoreInformation (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x84, 0x08, 0x25, 0xc9, 0x89
2020-01-03 10:52:06.495 Detail, Node014,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-01-03 10:52:06.496 Detail, Node014,   ZW_SEND_DATA delivered to Z-Wave stack
2020-01-03 10:52:06.564 Detail, Node014,   Received: 0x01, 0x18, 0x00, 0x13, 0xc9, 0x00, 0x00, 0x07, 0x00, 0xb3, 0x7f, 0x7f, 0x7f, 0x7f, 0x01, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x00, 0x8b
2020-01-03 10:52:06.564 Detail, Node014,   ZW_SEND_DATA Request with callback ID 0xc9 received (expected 0xc9)
2020-01-03 10:52:06.564 Info, Node014, Request RTT 75 Average Request RTT 79
2020-01-03 10:52:06.564 Info, Node014,   Node 14 has been marked as asleep
2020-01-03 10:52:06.564 Detail,   Expected callbackId was received
2020-01-03 10:52:06.564 Detail,   Expected reply was received
2020-01-03 10:52:06.564 Detail,   Message transaction complete
2020-01-03 10:52:06.564 Detail,
2020-01-03 10:52:06.564 Detail, Node014, Removing current message
2020-01-03 10:52:06.564 Detail, Node014, Notification: Notification - Node Asleep

Here’s what’s in the logbook for the same period:

image

Node014 is the Cold Cellar Flood Sensor which is the 3.02 sensor and Basement Flood Sensor is the 3.03 sensor. The 10:52 wake-up is not logged here or anywhere else in HA that I can find.

Everything else seems to work, the 3.02 sensor will send temperature updates when the threshold is met and HA will show the most recent temperature (though temp updates are never logged in the logbook for either sensor for whatever reason), it’s just the wake-ups that are missing.

I’ve tried excluding/including, using secure and unsecure modes, and so on, but the results are the same, the 3.03 sensor is well behaved and the 3.02 sensor’s wake-ups are mostly missed by HA. I can’t tell if the wake-ups are just not being logged but are otherwise being processed and queued messages are being sent to the sensor or if the wake-ups are not being seen at all by HA.

2

Did the state change on the wakeup from the previous state? Check the zwave entity, it should show an update every time something is sent or recieved. The devices that are created (i.e. sensors) may or may not update depending on the state. For example, if the state was 10 and the new state is 10, it won’t show an update on the sensor because nothing changed.

3

The z-wave entity does change state on the wake-up.

Here’s an example:

image
image362×807 40.6 KB

The device woke up at 17:38 as shown in the OZW log. In HA the sentTS and receivedTS are up to date and sentCnt, receivedCnt, and receivedUnsolicited all got incremented, but HA seems to think the device last woke up at 09:44.

Seems like a bug somewhere in HA.

4

Why are you hung up on if it’s being recorded as sleeping or not?

5

Well, unless the flood or tamper alarms are triggered you have to look at the entity or the OZW log to even know that the device is still working. It would be nice to just look at the logbook or integrate the last wake-up time into the UI somewhere so you know at a glance that your stuff is still working.

It’s also curious that one sensor works while the other doesn’t, even though they appear to behave the same way as far as the data being sent and received goes.

Anyway, from the debug logs it looks like the device awake state is sent from OZW but gets dropped somewhere between pyozw and HA, while the device sleeping state is processed properly but as far as HA knows the device didn’t change states, it just went from sleeping to sleeping, so nothing gets logged or updated in the UI. I’ll debug it some more soon.

6

If it’s not reporting as “Dead” then the device is working.

7

You’ll be wasting time as nothing is going to be done about this bug, if it is a bug. HA is moving to a new zwave system which will have the latest version of OZW. The whole architecture is changing, so everything is being rewritten in that regards.

1 Like
9

I do not know if this is also a zwave problem.
I made a test automation for my fibaro flood sensor. The actions are:
-Send notification
-Turn a lamp on

When I execute the automation manually it works. The lamp turns on and I get a notification on my iphone. However when I put the sensor into the water I see the sensor code is changing from 254 to 2 but nothing happens. No message and no lamp on.

Is this related to the bug Petro is refering?

- id: '1000000000006'
  alias: Zet stroom vaatwasser uit bij lekkage
  description: lekkage bij vaatwasser in keuken!
  trigger:
  - entity_id: binary_sensor.fibaro_system_fgfs101_zwave_flood_sensor_sensor
    from: '254'
    platform: state
    to: '2'
  action:
  - data:
      message: test
    service: notify.alert_xyz
  - data:
      entity_id: light.vloerlamp_tv
    service: light.turn_on
10

a binary sensor cannot have a state outside on/off.

11

Following on from what Petro said about binary sensors.
Even if you had an automation based on an attribute (which you are going for here) saying from 254 to 2 - precludes ANY other transition. eg 253 to 2 or anything in between.
The sensor is designed for this purpose, use the binary, let it sleep, alarm on low battery, alarm if its dead. Forget about anything else.

12

I checked several items in this forum and tried to script my solution without succes. Can someone help me with the code? Trail and error is the best but in this case I need code sopport. I test only on status “2”, this is the status when the sensor detect water. When status is 2 I want to receive a message on my iphone, turn off the power of the dishwasher via a Osram power plug. For the test I use a lamp. This is what I have:

- id: '1000000000006'
  alias: Zet stroom vaatwasser uit bij lekkage v2
  description: lekkage bij vaatwasser in keuken!
  trigger:
  condition:
    condition: template
    value_template: "{{ states('sensor.fibaro_system_fgfs101_zwave_flood_sensor_flood') | int == 2 }}"    
  action:
    service: notify.alert_xyz   
    data:
      title: "Test Title"
      message: "Test line"
    service: light.turn_on
    data:
      entity_id: light.vloerlamp_tv
13

Change the above to : -

  trigger:
    - platform: state
      entity_id: binary_sensor.fibaro_system_fgfs101_zwave_flood_sensor_sensor
      to: 'on'

From : -

  trigger:
    - entity_id: binary_sensor.fibaro_system_fgfs101_zwave_flood_sensor_sensor
      from: '254'
      platform: state
      to: '2'

A binary sensor (by definition) only has two states, ‘off’ and ‘on’ the ‘attributes’ (an attribute is different to a state, though it is splitting hairs) of the sensor can be a numeric but you don’t want that in this case

14

Thanks I will test it but one remark. In HA “States” the flood alarm is a sensor and not a binary sensor. Because of some items in the forum I defined a binary sensor for it which was as I under stand not the best idea. With the knowledge it is “sensor.fibaro_system_fgfs101_zwave_flood_sensor_flood” does this makes any difference to your code Mutt?

15

It shouldn’t but it depends on how you defined the binary sensor.
Have we seen that.?
(difficult to tell on a phone)
I’m away from home but I’ll repost if I discover something amiss.
Post the binary sensor anyway.

What do you get in the template editor with : -
“{{ states(‘sensor.fibaro_system_fgfs101_zwave_flood_sensor_flood’) }}”

Edit : no we’ve not seen your binary sensor
We need to know what is a reasonable trigger level, given what you’ve said it seems to report on a 0 to 255 level. I’m guessing, is 255 dry and 0 very wet.? Or is it the other way round ?

16

The value of the sensor is 0 or 254 when it sleeps. I have no clue why and when it change. When the sensor hits the water it changes to 2 and when it is out of the water it goes back to 254 or 0.

17

make a template sensor so you don’t have to deal with this crap

btw, off = 0
on = 2
and 254 = sleep.

most fibaro sensors work like this.

binary_sensor:
- platform: template
  sensors:
    flood:
      friendly_name: Flood Sensor
      value_template: >
        {% if is_state('sensor.fibaro_system_fgfs101_zwave_flood_sensor_flood','254') %}
          {{ states('sensor.fibaro_system_fgfs101_zwave_flood_sensor_flood') }}
        {% else %}
          {{ is_state('sensor.fibaro_system_fgfs101_zwave_flood_sensor_flood','2') }}
        {% endif %}

then to trigger

  trigger:
    - entity_id: binary_sensor.flood
      platform: state
      to: 'on'
18

Many thanks for your guidance Petro, it’s working now.

1 Like
19

My original problem is because of https://github.com/home-assistant/home-assistant/pull/6420. The sensor with the 3.02 firmware consistently wakes up and goes back to sleep within the 100 ms window so the sleeping->ready->sleeping transition is lost. The 3.03 one is a bit slower most of the time and doesn’t have its updates dropped. I changed that bit of code to confirm and the wake-ups for both devices are logged as expected.

I still don’t understand enough about HA’s code to know if this is a real problem or not, e.g. what happens if a sensor sends two important updates (e.g. flood and tamper) back to back, would one get dropped? Anyway, mystery solved.