Add support for Busch-Jaeger binary inputs 2-fach UP 6241/2.0 U & UP 4-fach 6241/4.0

[bitteeingit]

Hello,

first of all thank you very much for your efforts on this great plugin!

Are there any plans to integrate Busch Jaeger's binary inputs in the near future?

Thx in advance for your reply!

[henry-spanka]

Hi, thanks.

I already worked on integrating binary inputs before but abandoned it because I had no use for it.

As a binary input usually means some event happened, we need to allow the user to change the sensor type that is exposed to HomeKit(e.g. MotionSensor, ContactSensor, AirQualitySensor, CarbonDioxideSensor, ...).

Can you please elaborate which sensors you think are useful and you need for your home? Under which condition is the edge of the binary input rising and falling?

[bitteeingit]

Hi, Thanks for your quick reply. I gonna use the those binary inputs for analyzing the states of my door/window reed contacts. I also have a Busch-Jaeger Relais 6829-84 which is linked to the smoke sensors and its relais is connected to such a binary input. So, in my case the service types would be ContactSensor and SmokeSensor. But as you said you can utilise them for evaluating lots of different sensors types as long as they have an alarm output possibility, like a relais. The trigger condition should be the positive edge I think. As you also have the ability to change the I/O behaviour between open/close within the Busch Jaeger configuration tool...

[henry-spanka]

Hi, you're right. The condition can be set in the free@home access point web interface.

Please post your actuator details (sensor triggered and sensor not triggered). You can get them by executing curl http://localhost:8080/info > actuator_snapshot.json on your home bridge server. You may want to hide your serial numbers before posting your snapshot online.

I'll try to integrate basic support (rising edge -> alarm, falling edge -> no alarm) in about a week.

[bitteeingit]

Hi,

please find an excerpt --> snapshot_binary-actuators_excerpt.txt of the actuator_snapshot.json including all my binary inputs attached (6x 2-fach, 1x 4-fach 6241/4.0 - I forgot to mention that there's also a REG 4-fach binary input in my setup :-). Hopefully the file contains all info you need. I recognized that even if they are obviously the same device they do have different datapoints. Just two guys have the same values. Maybe this is related to my config in the free@home access point web interface. Therefore I added this info in addition to the file. Don't know whether it helps or not.

Thanks you very much in advance!

[henry-spanka]

Thank you. Can you please also check which datapoint changes? I think it's odp000C but some of your devices have other datapoints.

[bitteeingit]

Sorry, but I didn‘t get it. what do you mean with „...check with datapoint changes?“

[henry-spanka]

Sry, blame autocorrection ;). Please check which datapoint changes when the binary input is triggered.

[bitteeingit]

:) Can you quickly describe how I can check this? Thx

[henry-spanka]

Sure.

1. Get actuator data: curl http://localhost:8080/info > actuator_snapshot.json
2. Trigger binary input
3. Quickly get actuator data again: curl http://localhost:8080/info > actuator_snapshot_2.json

Something should have changed between the files.

[bitteeingit]

You were right. The comparison shows that the datapoint "odp000C" changes when it's triggered. But there's a difference between NO and NC configured actuators. It seems that the allocation "triggered = "1" and "untriggered" = "0" is not vaild. In fact an open circuit leads to "1" and a closed circuit to 0. I don't know whether I described it well and if it matters but I wanted to highlight it :-)

normally closed actuator:

• untriggered:

"ABBxxxxxxxx":{"serialNumber":"ABBxxxxxxxxx","deviceId":"B005","typeName":"Binäreingang 2-fach, UP","channels":{"ch0000":{"datapoints":{"odp000C":"0","pm0000":"2"}},"ch0001":{"datapoints":{"odp0000":"0","pm0000":"1","pm0001":"1"}}}}

• triggered:

ABBxxxxxxxxx":{"serialNumber":"ABBxxxxxxxxx","deviceId":"B005","typeName":"Binäreingang 2-fach, UP","channels":{"ch0000":{"datapoints":{"odp000C":"1","pm0000":"2"}},"ch0001":{"datapoints":{"odp0000":"0","pm0000":"1","pm0001":"1"}}}}

Normally open actuator:

• untriggered

"ABBxxxxxxxx":{"serialNumber":"ABBxxxxxxxx","deviceId":"B005","typeName":"Binäreingang 2-fach, UP","channels":{"ch0000":{"datapoints":{"odp000C":"1","pm0000":"1"}},"ch0001":{"datapoints":{"odp0000":"0","pm0000":"1","pm0001":"1"}}}}

• triggered

ABBxxxxxxxxxx":{"serialNumber":"ABBxxxxxxxx","deviceId":"B005","typeName":"Binäreingang 2-fach, UP","channels":{"ch0000":{"datapoints":{"odp000C":"0","pm0000":"1"}},"ch0001":{"datapoints":{"odp0000":"0","pm0000":"1","pm0001":"1"}}}}

[henry-spanka]

Thanks. Unfortunately my binary input (Schaltaktor 8/8-fach) does have other datapoints, so I will now try to add basic support for the actuators you mentioned and hope that it works.

[bitteeingit]

Understand. We will see :-) But anyway thank you very much for your support!

[bitteeingit]

Hi, I would like to kindly ask when you think it will be implemented ? Thanks in advance.

[henry-spanka]

Hi, sry for the delay. I have added basic support in commit ba01f1eb858a7992d34e16b70dabb1c8a70ae15a.

Unfortunately my actuators have different datapoints so you need to configure them by hand.

Please add to your config file:

"ABBxxxxxxxxx": {
  "binarysensor": {
      "chXXXX": { // Channel
        "datapoint": "odp0000C",
        "type": "ContactSensor", // Or SmokeSensor
        "invert": false // If true then the input triggers when it's 0
      }
  }
}

Note: You need to update the plugin first from the master branch. Replace the dependency in package.json with "homebridge-buschjaeger": "henry-spanka/homebridge-buschjaeger#master" and run npm install.

[bitteeingit]

Hi, thank you!

Regarding your note: Could you please eloborate in more detail what I exactly have to do? I don't want to screw up everything :-) Sorry for the inconvenience!

[henry-spanka]

Hi, sure. Edit the package.json file in your homebridge root directory and replace

{
  "homebridge-buschjaeger": "^1.X.X"
}

with

{
  "homebridge-buschjaeger": "henry-spanka/homebridge-buschjaeger#master"
}

After that you can run npm install (also in the root directory of homebridge).

[bitteeingit]

Hello, sorry for bothering you again. To be clear: I opened the package.json in this directory: /usr/local/node_modules/homebridge-buschjaeger

In this file I didn't find: { "homebridge-buschjaeger": "^1.X.X" } but { "_from": "homebridge-buschjaeger", "_id": "homebridge-buschjaeger@1.6.0", ... "bundleDependencies": false, "dependencies": { "extend": "^3.0.0", "ip": "^1.1.3", "node-persist": "2.0.x", "npm": "^5.7.1", "ws": "^4.1.0" }, ... I don't know exactly what to exchange now...

[henry-spanka]

Hi, ah, you have installed it globally, my bad.

Try: npm install -g henry-spanka/homebridge-buschjaeger#master You can try to uninstall the module first if it doesn't work.

[bitteeingit]

Hello, I just tried it but I got attached error log despite I added every actuator with its SN exactly as described to the config.json. Do I have to allocate every datapoint or maybe blacklist the not used ones? log.txt Thx for your help!

[henry-spanka]

Hi, thanks. I should probably add checks to prevent a crash. Can you please post your config.json (hide any sensitive data if necessary, like PIN, MAC)?

[henry-spanka]

You need to blacklist all channels that are not used (no entry in the "binarysensor" section) for your Binary Sensor Actuators.

I guess I will make the actuators whitelist only until the next release.

[henry-spanka]

@bitteeingit I have added some commits that should prevent homebridge from crashing. Please reinstall the plugin again and whitelist your binary sensor channels (any other will automatically be ignored).

[bitteeingit]

Ok, you mean e.g for a 2-fach UP 6241/2.0 sth like this:

"ABBXXXXXXXXX": { "binarysensor": { "ch0000": { "datapoint": "odp0000C", "type": "ContactSensor", "invert": false }, { "blacklist": ["ch0001"] } } } pls. find the config.json attached: config.txt

[henry-spanka]

Thanks, please additionally whitelist each binary sensor channel you use, e.g. for ABBXXXXXXXXX:

"ABBXXXXXXXXX": {
  "whitelist": ["ch0000"],
  "binarysensor": {
      "ch0000": { 
        "datapoint": "odp0000C",
        "type": "ContactSensor",
        "invert": false 
      }
  }
},

[bitteeingit]

Ok, will try and give feedback! thx!

[bitteeingit]

Hi, I tried it today with whitelisting. Unfortunately it didn't work out. I got the binary sensor displayed in HK but it didn't change its state: pls see log:

Updating accessory Binäreingang 2-fach, UP Channel 0000 with uuid ABBXXXXXXXXXX [2019-8-26 20:58:04] [F@H] Received a message from websocket [2019-8-26 20:58:09] [F@H] Accessory is already turned on/off [2019-8-26 20:58:10] [F@H] Accessory is already turned on/off

Maybe a rising/falling edge is needed. Because I always see two lines in the terminal when an actuator is triggered...I don't know...

In addition another issue appeared: My garagedoor got its own life: it opened, it closed, then it opened aso... After removing "ABBXXXXXX":{"garagedoor": {"ch0010" {"movingUpTime":14,"movingDownTime":18,"triggerTime":1}} from config.json it went away. Maybe it is related to jumping from 1.5.3 to 1.6.0 I just downgraded back to 1.5.3 as my shutters were not reliable anymore. But maybe this should be discussed seperately :-)

[henry-spanka]

Hi, which type have you selected in the free@home control panel for your binary sensor?

I have already noticed such behaviour with my test sensor. The problem is that the sensor will only change from 0 -> 1 for a few milliseconds and then go back to the initial state. So we're reading back the old value which causes HomeKit to not recognise the change. I will try to fix that tomorrow.

The pushed updates should have no effect on the Garage Door. Please include the log file when the issue happens again. I'm not using the Garage Door actuator accessory anymore because I have integrated it directly via I2C in HomeKit but I couldn't notice any unusual behaviour in the past.

In 1.5.4 I have removed legacy code for the shutter accessory because free@home can natively move the shutter into a specific position (percentage). Before I have manually calculated how long the shutter needs to move to be in a specific position and then manually sent the stop signal to the actuator. I believe that the new implementation is much cleaner and expected that the actuator should handle this well. Can you please explain what you mean with "unreliable"? In my setup I have seen an improvement with the new implementation. The only issue is that the shutter may stop for a sec and then move again, but it should always move to the requested state (+/- ~5%).

[bitteeingit]

Hi, I selected "Fensterkontakt" for the binary sensor. This is necessary to display them as a door contact in the free@home GUI. Just a few ms? Ok, that means you have to "catch" the positive edge and save the state?

I don't know what's wrong with my garagedoor, but it immediately happened after starting homebridge with the new branch. Which kind of log do you need. Tell me how to get the right info for you please.

Ok maybe I was a bit ambiguous. You're right the shutters move much more accurate but I encountered some annoying stuff within HK. Some of my shutter icons are showing movement despite the coressponding shutter is not moving. I have to click on the icon and then the icon stops showing movement. Unfortunately the issue comes back after a real movement... You haven't this issue in HK?

[bitteeingit]

Hi, I'd like to ask if you had the time to update your code? thanks!

[henry-spanka]

Hi, I'm sorry for the delay. Unfortunately I don't have a solution yet as it's currently not possible to integrate the changes needed for binary inputs to work. At this moment it's not possible for the plugin to detect short changes (a few ms) of a datapoint.

I will take a look at it again next week.

[bitteeingit]

Hi, no problem. Looking forward to getting it fixed.

Thanks for your efforts!

[henry-spanka]

Hi, I have pushed another commit. Please update the plugin again and add the following config option to the binarysensor section: "stopDelay": 10 (seconds to wait before disabling the sensor).

[bitteeingit]

Hi, thank you! I'll test it latest on the WE. Beforehand: disabling of the sensor means what exactly?

[henry-spanka]

Hi, it means that the sensor is inactive (not triggered).

[bitteeingit]

Hi, I tried it yesterday in short dry run with only one binary sensor to be exposed to the system configured like this:

"ABB0000001": { "whitelist":["ch0000"], "blacklist":["ch0001"], "binarysensor": { "ch0000": { "datapoint": "odp0000C", "type": "ContactSensor", "invert": false, "stopDelay": 10
} }

In the logfile all binarys are listed but they were ignored , also the one I explicitly configured in the config.json:

[2019-9-28 15:38:38] [F@H] Ignoring non-whitelisted accessory Binäreingang 2-fach, UP with serial ABB00000001 and channel ch0000 [2019-9-28 15:38:38] [F@H] Ignoring non-whitelisted accessory Binäreingang 2-fach, UP with serial ABB00000001 and channel ch0001

I also got some unexpected behaviour from HK. Some of my actuators lost their room allocation + name and showed the ABB actuator modell and channel instead. That wouldn’t be a problem though but HK also began to loose connection to homebridge and toogled between updating the tiles and being connected- Don’t know what could be the reason but HK was unusable.

[henry-spanka]

Hi, your config looks correct. Are you sure the serial number is correct?

I couldn't notice any unexpected behaviour in HomeKit. Which version of the System Access Point firmware do you use and have you upgrade to iOS 13 recently?

I'm running iOS 13 and everything works as expected.

[bitteeingit]

Hi, it's just a dummy number :-) Hmm, ok, I am running iOS 13.1.1 and the System Access Point firmware is 2.1.7.

[henry-spanka]

Please post your complete configuration. You can of course hide the MAC, serial number and Pin, etc.

[bitteeingit]

Hi, sorry for the late feedback. So I haven't changed anything to my config posted earlier in our chat beside the test code lines for binary sensor. I found out that the toggling of the tiles was due some network issues. I did another dry run but after updating to your latest master I got following error log:

[2019-10-6 12:34:38] TypeError: Cannot read property 'displayName' of undefined at BuschJaegerDimmAktorAccessory.getChannelAttribute (/usr/local/lib/node_modules/homebridge-buschjaeger/lib/BuschJaegerAccessory.js:140:55) at BuschJaegerDimmAktorAccessory.BuschJaegerAccessory (/usr/local/lib/node_modules/homebridge-buschjaeger/lib/BuschJaegerAccessory.js:24:22) at new BuschJaegerDimmAktorAccessory (/usr/local/lib/node_modules/homebridge-buschjaeger/lib/BuschJaegerDimmAktorAccessory.js:9:42) at BuschJaegerApPlatform.transformAccessories (/usr/local/lib/node_modules/homebridge-buschjaeger/index.js:118:37) at BuschJaegerApPlatform.processMessage (/usr/local/lib/node_modules/homebridge-buschjaeger/index.js:259:14) at WebSocket.incoming (/usr/local/lib/node_modules/homebridge-buschjaeger/index.js:236:14) at WebSocket.emit (events.js:180:13) at Receiver._receiver.onmessage (/usr/local/lib/node_modules/homebridge-buschjaeger/node_modules/ws/lib/websocket.js:137:47) at Receiver.dataMessage (/usr/local/lib/node_modules/homebridge-buschjaeger/node_modules/ws/lib/receiver.js:409:14) at Receiver.getData (/usr/local/lib/node_modules/homebridge-buschjaeger/node_modules/ws/lib/receiver.js:347:12)

[henry-spanka]

Hi, thanks for the hint. I have fixed the issue. It was introduced in the last commit.

[bitteeingit]

Ok, now it starts but with same behaviour as mentioned above

Hi, I tried it yesterday in short dry run with only one binary sensor to be exposed to the system configured like this:

"ABB0000001": { "whitelist":["ch0000"], "blacklist":["ch0001"], "binarysensor": { "ch0000": { "datapoint": "odp0000C", "type": "ContactSensor", "invert": false, "stopDelay": 10 } }

In the logfile all binarys are listed but they were ignored , also the one I explicitly configured in the config.json:

[2019-9-28 15:38:38] [F@H] Ignoring non-whitelisted accessory Binäreingang 2-fach, UP with serial ABB00000001 and channel ch0000 [2019-9-28 15:38:38] [F@H] Ignoring non-whitelisted accessory Binäreingang 2-fach, UP with serial ABB00000001 and channel ch0001

In addition HK shows a bunch of actuator channels which are blacklisted in the config.json

[henry-spanka]

Hi, I don't really see any issues here. Can you please post your complete configuration (hide PIN, MAC and serial no). You can also send it to my email address (see my GitHub profile) if you like.

[bitteeingit]

I just send an email.

[henry-spanka]

Is this still relevant?

[Mischmasch44]

Hi, I still have a problem with my 6241/2.0 binary sensors, as they do not show a status change in HK when opened or closed. The Homebridge log shows an update every minute from the time first opened (NC) and stops if closed again. As I said, the HK accessory doesn‘t display the change. I use the binary sensors as reed contacts for windows/doors. I appreciate your work for this plugin. :)

[henry-spanka]

hmm that shouldn't happen. Please enable homebridge debug mode and post the logs when you open/close the window.

[dom3007]

Hello, is there already a solution for this problem ?

[henry-spanka]

Hello, not yet. As said in my previous message I need the logs to be able to reproduce this.

[dom3007]

I tried to filter it. It's about the window contact in the office. I opened the window and then closed it again

[30/12/2022, 22:42:08] [BuschJaegerSysAp] Updating accessory FK Büro with uuid ABB2283C2251ch0001

} } [30/12/2022, 22:42:16] [BuschJaegerSysAp] Updated Datapoint: ABB2283C2251/ch0001/odp000C/0 [30/12/2022, 22:42:16] [BuschJaegerSysAp] Updated Datapoint: ABB6630A9E5E/ch0025/idp0000/0 [30/12/2022, 22:42:16] [BuschJaegerSysAp] Updated Datapoint: ABB700C9C7AF/ch0000/idp0015/0 [30/12/2022, 22:42:16] [BuschJaegerSysAp] Updated Datapoint: ABB6630A9DE3/ch0025/idp0000/0 [30/12/2022, 22:42:16] [BuschJaegerSysAp] Updating accessory FK Büro with uuid ABB2283C2251ch0001

[henry-spanka]

Thanks, please also send me a backup of your system access point ("Projektsicherung") to my email listed on my GitHub profile. You can download the file in the web ui of the system access point.