Garage Doors do not show proper status

[Chioti]

I've set up my 3 garage door i/o lyncs and and they all show up in homekit correctly as garage doors. However their statuses do not appear correct when homebridge starts up. If I open and close the doors using a keypad link their statuses do not update. I have logging turned on, what can I do to debug the issue?

[rodtoll]

@SteliosMakrinos - Sorry to hear things aren't working for you.

First thing to check is when homebridge starts up does it show the status of the doors as opposite of what they are? If so it means your garage door sensor is configured to be opposite of mine.

If it is opposite then this is the cause. Because these kits can't tell us status beyond open or closed (i.e. they can't tell you opening, or closing) the library needs to start in a well known state and if my logic is backwards for your setup you'll see weird effects like that. I put some logic in there to fix that up after it opens and closes but I may have missed something.

If that's it then I can whip up a fix allowing you to select the opposite behavior and things should work.

If that's not it then close your garage door, startup Homebridge with homebridge-isy-js configured with debug output, let it startup and then open the garage door, let it go all the way open and then close it and let it go all the way closed and then send me the debug output here.

Also, it will be good to have you post the portion of your config with the garagedoors in it. i.e. the garageDoors element from the config.json file.

We'll figure this out. Thanks.

[Chioti]

Although I don't believe it is the only problem, you are correct, when homebridge starts up it is reporting the opposite state from what the sensors are and from what is shown in the ISY administrator.

[rodtoll]

@SteliosMakrinos

You could absolutely be correct. Let's tackle the reversed state first and if it is still not fixed we can do more troubleshooting.

If you have some familiarity with javascript you can try patching your local copy and see if it fixes things. If you'd rather not, that's ok as well. I'll code up something you could try later today, early tomorrow.

Here are the changes you would need to make:

index.js, Line 899. Change: if(sensorDevice.getCurrentDoorWindowState()) { to: if(!sensorDevice.getCurrentDoorWindowState()) {

index.js, Line 994. Change: if(this.device.getCurrentDoorWindowState()) { to: if(!this.device.getCurrentDoorWindowState()) {

If you do try this and it is still not fixed, please capture debug output like I described earlier.

Thanks!

[Chioti]

I made the local changes. Now the initial statuses are correct, however when I opened 2 doors with they keypad, the statuses did not update to "open".

Here is the output: Node: 3B 90 40 3 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 46962 changed Node: 3B 90 40 5 changed Node: 00:21:b9:02:27:f6 changed Node: 31930 changed Node: 834 changed Node: 34 8E 6F 1 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 34 8E 4 1 changed Node: 00:21:b9:02:27:f6 changed Node: 834 changed

[PaulWieland]

For what it's worth, theres a preferred way to wire the iolinc sensor for garage door. If you wire it normally open, your keypad light will be inverted from the actual state if the iolinc loses power.

From UDI Wiki:

NOTE: If the I/OLinc loses power for any reason, the Trigger Off gets reset back to off (unchecked). This causes the keypad button light to be inverted and give a false indication of the garage door status until you reprogram the I/OLinc. As this can happen often, I would highly recommend that you use the RED and BLACK wires from the reed switch and NOT the Green wire (NC or Normally Closed reed switch operation).

Sent from my iPhone

On Feb 13, 2016, at 2:04 PM, SteliosMakrinos notifications@github.com wrote:

I made the local changes. Now the initial statuses are correct, however when I opened 2 doors with they keypad, the statuses did not update to "open".

Here is the output: Node: 3B 90 40 3 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 46962 changed Node: 3B 90 40 5 changed Node: 00:21:b9:02:27:f6 changed Node: 31930 changed Node: 834 changed Node: 34 8E 6F 1 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 34 8E 4 1 changed Node: 00:21:b9:02:27:f6 changed Node: 834 changed

— Reply to this email directly or view it on GitHub.

[rodtoll]

@SteliosMakrinos

We'll need to dig in deeper as to what is happening inside the Finite State machine that runs inside each garage accessory.

I've been looking through the code to figure out why your debug output is coming out correctly and I think I figured it out. You need to run homebridge with the -D command-line option to turn on debug logging in addition to the debugLoggingEnabled option being set to true. Once you have done both you should see output specific to the garage and it will tell us what is happening. It will look something like this:

[isy-js] 116-1-6#19:40:59- GARAGE: Garage Door SensorCurrent state of door is closed and now sensor says open. Setting state to opening [isy-js] 116-1-6#19:40:59- GARAGE: Ignoring redundant set of target state [isy-js] 116-1-6#19:41:11- GARAGE: Garage Door SensorCurrent door has bee opening long enough, marking open

That is the output we'll need to figure out what is happening.

If you open and close the door only from HomeBridge/Siri does the state track correctly?

[rodtoll]

For reference my setup is wired with the red and black.

[rodtoll]

And one more question -- when you say the state does not go to Open -- is it in opening state or some other state?

[Chioti]

No, it shows "Closed".

I started it with -D, but it doesn't appear as you say.

Using the keypad, I opened one of the doors and got: Node: 3B 90 40 3 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 46962 changed Node: 34 8E 6F 1 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed

[Chioti]

clicking it again to close first gave me: Node: 00:21:b9:02:27:f6 changed

and then when it closed: Node: 3B 90 40 3 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 46962 changed Node: 34 8E 6F 1 changed Node: 00:21:b9:02:27:f6 changed Node: 41728 changed Node: 29 F0 10 1 changed Node: 00:21:b9:02:27:f6 changed Node: 227 changed

[rodtoll]

@SteliosMakrinos - Let's switch to a live chat and work through this. If you are interested, join me on my slack here: https://troublex3.slack.com/, general channel. If you can't join you will need an invite. E-mail me your e-mail address to rod_tollAThotmail.com (replace AT with @) and I'll send you an invite.

[rodtoll]

Alternatively, if you'd rather not you can force debug output by changing this line (should be line 51 in index.js) from:

    this.log(timeStamp.getYear()+"-"+timeStamp.getMonth()+"-"+timeStamp.getDay()+"#"+timeStamp.getHours()+":"+timeStamp.getMinutes()+":"+timeStamp.getSeconds()+"- "+msg);

to:

    console.log(timeStamp.getYear()+"-"+timeStamp.getMonth()+"-"+timeStamp.getDay()+"#"+timeStamp.getHours()+":"+timeStamp.getMinutes()+":"+timeStamp.getSeconds()+"- "+msg);

That will force debug output. If your copy of index.js doesn't look like the above then you might be a version behind. In which case you need to do an npm update.

I'll hang on the slack channel for 30 minutes just in case.

[Chioti]

Unfortunately I'm tied up the rest of the night. I'll email when I can and see if we can find a time to work through it.

On Feb 13, 2016, 4:13 PM -0500, rodtollnotifications@github.com, wrote:

Alternatively, if you'd rather not you can force debug output by changing this line (should be line 51 in index.js) from:

this.log(timeStamp.getYear()+"-"+timeStamp.getMonth()+"-"+timeStamp.getDay()+"#"+timeStamp.getHours()+":"+timeStamp.getMinutes()+":"+timeStamp.getSeconds()+"- "+msg);

to:

console.log(timeStamp.getYear()+"-"+timeStamp.getMonth()+"-"+timeStamp.getDay()+"#"+timeStamp.getHours()+":"+timeStamp.getMinutes()+":"+timeStamp.getSeconds()+"- "+msg);

That will force debug output. If your copy of index.js doesn't look like the above then you might be a version behind. In which case you need to do an npm update.

I'll hang on the slack channel for 30 minutes just in case.

— Reply to this email directly orview it on GitHub(https://github.com/rodtoll/homebridge-isy-js/issues/16#issuecomment-183755488).

[rodtoll]

No problem. If you get a chance try the change I suggest up above and collect the debug output along with a note saying what sequence you went through (i.e. opened and let it open through homekit then closed it through homekit). Then when I might be able to figure out what is going wrong. If not we can meet on slack sometime that works for us both.

[Chioti]

which index.js are you referring to? I don't see it at all in the index.js or your plugin.

[rodtoll]

If you don't see the above line in index.js of the homebridge-isy-js directory then you don't have the latest version of the plugin. You'll need to update by running: sudo npm update -g homebridge-isy-js

The above assumes you are running on mac OSX or Linux or raspberry pi.

[rodtoll]

Once you do an update you'll need to re apply the earlier changes you made as they will be over written by the update.

[Doughboy68]

I'll add here that mine is working fine although I previously added a resistor to my sensor wire on IOLinc to reverse the NC because my garage door sensor only has two wires and I couldn't make it NO.

[Doughboy68]

http://forum.universal-devices.com/topic/10954-bug-when-using-iolinc-trigger-reverse-checkbox/ I think a 470 ohm is wht works.

[rodtoll]

@SteliosMakrinos - I just released v. 0.1.4 of the homebridge-isy-js plugin. It has a new option when you specify a garage entry in the config to reverse the sensor logic. Just add an additional attribute called "alternate" in the garage entry and set it to true. Then try to see if this fixes your issue.

Sample: { "address": "17 79 81 1", "name": "Garage Door", "timeToOpen": 12000, "alternate": true }

Just do a: sudo npm update -g homebridge-isy-js to update to the latest.

[rodtoll]

To update folks on this issue. We got @SteliosMakrinos working. There still remains to be a few cases where you can get into a state where the system doesn't know what state the door is in temporarily. Specifically when the door is open when you start up and the door motor is activated. It's unclear if the motor is opening the garage door or closing it -- so the state doesn't change until the sensor does. This is because the motor doesn't have a direction associated with it that we can access.

Noodling on the right thing to do here but the issue is now different so closing this one.