offValues array not working properly in Homebridge-HomeSeer4

[rrman]

Hi,

First, many thanks for a wonderful plug-in!

I just upgraded from homebrige-homeseer-plugin-2018 (version 2.4.2) to homebridge-homeseer4 (version 1.0.2).

It looks like homebridge-homeseer4 doesn't properly handle the offValues array.

I have two Fibaro Flood sensors (FGFS-101). This sensor has two possible values for Off (meaning the sensor is dry): 0 and 254. My config.json has two entries for these two sensors:

    {
      "type": "LeakSensor",
      "name": "Basement Water Heater Leak",
      "ref": 712,
      "offValues": [
        0,
        254
      ]
    }

... { "type": "LeakSensor", "name": "Laundry Water Sensor", "ref": 705, "offValues": [ 0, 254 ] }

Currently, both sensors have the value 254 in HomeSeer. The old version of the plugin, homebridge-homeseer-plugin-2018, correctly used the offValues array. However, with homebridge-homeseer4, when these devices have value 254, they show up as "Triggered" in the iOS Home app.

I manually forced these devices to have the status of 0 by running these 2 commands:

&hs.SetDeviceValueByRef(712, 0, True) &hs.SetDeviceValueByRef(705, 0, True)

As expected, these two devices no longer show up in the iOS Home app with status "Triggered".

However, as soon as I set their status to 254, they show up as "Triggered" again.

So, it seems that homebridge-homeseer4 doesn't process the offValues array correctly. I have other types of flood/leak sensors, and they only have one possible status for dry, which is 0. For those sensors, I have:

      "offValues": [
        0
       ]

In other words, for these other flood/leak sensors, they only have one entry (0) in their offValues array. These devices show up correctly in iOS Home app. But when there is more than one value in offValues, only 0 is being processed properly (and not 254).

Regards,

Randy

[jvmahon]

Actually, that's because of a "fix" I made.

The "off" value should actually be 0.
254 means the sensor is in an "Unknown" state.

So, if the HomeSeer reports "254" what should happen is that HomeKit will then show the sensor as being in a "Triggered" state, but if you then tap on the sensor in the Home app, you'll see that it says "Fault Detected" rather than "Leak Detected."

I think this is the correct way for it to work - but if it creating a significant issue, let me know - I can reorder the code such that, if "off" includes "254" it will just use that and ignore the fault detection.

This "Fault Detected" warning then alerts you to go and see what is happening in HomeSeer. I also have an event in HomeSeer that I can manually activate to clear the "unknown" state of all my sensors. I use the Easy Trigger plugin and set a group containing all of my leak sensors which I then force to a "0" state if any become set to 254 = unknown.

[rrman]

Yes, you're right 254 is technically "Unknown". This reminds me that the reason I included 254 as one of the offValues is due to a bug, I believe in HomeSeer. If the sensor is dry (status value = 0), and I poll the sensor from HomeSeer, the sensor's state changes from 0 to 254. If the sensor's state is Wet (status value = 2), and I poll the sensor from HomeSeer, the sensor's state remains wet (status value = 2). It's only if the sensor is dry will polling cause it to change state to 254. Hence, I treat 254 synonymously as 0 (both dry), which is why I had both in the offValues array. I can write events to automatically change the state to 0 whenever the state becomes 254, but I thought, at least in the previous version of the plug-in I was able to use the offValues array to just treat 254 as a dry state.

Now, I do have the First Alert - ZCOMBO smoke/carbon monoxide detector. It has two states that are considered "good/normal" states:

0: No Notification 13.255: Alarm Heartbeat (yes, that's 13.255, so not an integer in case it makes a difference in the latest plug-in).

I have two of these smoke detectors, and they are defined as follows:

      "type": "SmokeSensor",
      "name": "Landing Smoke/CO",
      "ref": 338,
      "offValues": [
        0,
        13.255
      ],
      "batteryRef": 339,
      "batteryThreshold": 80
    },
    {
      "type": "SmokeSensor",
      "name": "Living Room Stairs Smoke/CO",
      "ref": 341,
      "offValues": [
        0,
        13.255
      ],
      "batteryRef": 342,
      "batteryThreshold": 
   }

This worked fine in the previous version of the plug-in. Normally, their state is actually 13.255. I assume that the new version of the plug-in will work fine?

I haven't been able to confirm that above will work yet, though.

I have 6 homebridge services: homebridge1, homebridge2, ... homebridge6. One of the six, homebridge5, is used to run the Camera-ffmpeg plug-in. Five of the six are exclusively for the homebridge-homesee4 plug-in (homebridge1, homebridge2, homebridge3, homebridge4, and homebridge6). Out of these 5 services, one of them (homebridge4) does not stay up. I start it and then it shuts down, and systemctl tries to keep restarting it. I can't figure out why it won't stay up. I tried removing some accessories, but it still won't stay up.

Jun 24 18:29:55 homebridge systemd[1]: homebridge4.service: Main process exited, code=exited, status=143/n/a Jun 24 18:29:55 homebridge systemd[1]: homebridge4.service: Failed with result 'exit-code'. Below is output from /var/log/syslog:

Jun 24 18:30:13 homebridge homebridge[10200]: [6/24/2020, 6:30:13 PM] Error: listen EADDRINUSE: address already in use :::51824 Jun 24 18:30:13 homebridge homebridge[10200]: at Server.setupListenHandle [as _listen2] (net.js:1313:16) Jun 24 18:30:13 homebridge homebridge[10200]: at listenInCluster (net.js:1361:12) Jun 24 18:30:13 homebridge homebridge[10200]: at Server.listen (net.js:1447:7) Jun 24 18:30:13 homebridge homebridge[10200]: at EventedHTTPServer._this.listen (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/util/eventedhttp.ts:85:21) Jun 24 18:30:13 homebridge homebridge[10200]: at HAPServer._this.listen (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/HAPServer.ts:236:22) Jun 24 18:30:13 homebridge homebridge[10200]: at Bridge.Accessory._this.publish (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:974:18) Jun 24 18:30:13 homebridge homebridge[10200]: at Server.publishBridge (/usr/lib/node_modules/homebridge/src/server.ts:192:17) Jun 24 18:30:13 homebridge homebridge[10200]: at /usr/lib/node_modules/homebridge/src/server.ts:164:24 Jun 24 18:30:13 homebridge homebridge[10200]: at processTicksAndRejections (internal/process/task_queues.js:97:5) Jun 24 18:30:13 homebridge homebridge[10200]: at Server.start (/usr/lib/node_modules/homebridge/src/server.ts:163:5) Jun 24 18:30:13 homebridge homebridge[10200]: [6/24/2020, 6:30:13 PM] Got SIGTERM, shutting down Homebridge... Jun 24 18:30:13 homebridge homebridge[10200]: [6/24/2020, 6:30:13 PM] [HomeSeer] Successfully connected to ASCII Control Interface of HomeSeer. Jun 24 18:30:13 homebridge homebridge[10200]: [6/24/2020, 6:30:13 PM] [HomeSeer] Sent Authorization Data Jun 24 18:30:13 homebridge homebridge[10200]: [6/24/2020, 6:30:13 PM] [HomeSeer] Successfully authorized Telnet port Jun 24 18:30:18 homebridge systemd[1]: homebridge4.service: Main process exited, code=exited, status=143/n/a Jun 24 18:30:18 homebridge systemd[1]: homebridge4.service: Failed with result 'exit-code'.

Any tips on how to further debug this issue?

Regards.

[rrman]

Update: somehow, my homebridge6 service had some conflicts with my homebridge4 service, which was causing one of the two to fail to startup. So, I think my issue from my earlier post about homebridge4 not starting up was due to the conflict which I've resolved (either that or I had to mess with my Garage Door status page to specify Door Lock and Door Unlock as discussed in my other ticket, but I don't think the Garage issue was related to the crash).

Oh, one more thing: I have a number of smoke sensors. All of them specify the "name" parameter in config.json. However, when the devices are added to HomeKit, all of the smoke sensors are named "Smoke Sensor" instead of the value of "name" in config.json. But this is an old issue dating back to the 2018 plug-in.

Anyway, so far so good. Thanks for the wonderful plug-in.

[rrman]

BTW, I added two events so anytime my flood sensors change to 254 (which occurs when HomeSeer polls them), the events change them back to 0 (dry). But, as I indicated earlier, for my Smoke sensors, I still use two values in the offValues array:

{
  "type": "SmokeSensor",
  "name": "Living Room Stairs Smoke/CO",
  "ref": 341,
  "offValues": [
    0,
    13.255
  ],
  "batteryRef": 342,
  "batteryThreshold": 

}

So, I hope the new plug-in still works for those two values (0 and 13.255). I haven't tested my smoke sensors yet (I don't want to wake anyone up at this time).

[jvmahon]

If your sensors are battery operated, then it would be typical to turn off polling for the device since they won't poll anyway - have you tried that? I've noticed that sometimes HomeSeer improperly configures polling - some of my sensors were set to a polling time of 0 / 0 / 0 (no polling) while others had polling set. The proper setting is to poll at 0 hours, 0 minutes, 0 seconds (polling off).

[rrman]

Yes, I have polling turned off for just about all my devices (including the flood sensors). I do poll under the following conditions, as an insurance policy to verify that all HomeSeer reflects the correct state of all my devices:

1. I have an event that runs once a week in the middle of the night that polls all my Z-Wave devices.
2. When HomeSeer starts, it checks when it was last running. If it's been down for 15 minutes or so, an event runs that polls all my devices.

Hence, it's not often that polling takes place, but when it does, somehow HomeSeer incorrectly changes the states of some devices (like the flood sensors) to unknown state (254).

Anyway, I've written a couple of events to change state 254 to state 0 for my flood sensors, so the OffValues array for these flood sensor devices only include 0 now.

Regards,

Randy