Is it possible to integrate the wireless window sensor?
I mean this component: https://www.busch-jaeger.de/produktuebersicht?tx_nlbjproducts_catalog[action]=show&tx_nlbjproducts_catalog[catBjeProdukt]=3660&tx_nlbjproducts_catalog[catStdArtikel]=3876&tx_nlbjproducts_catalog[controller]=CatStdArtikel&cHash=898316c3918f833e128df1a7a5e8e250
Window sensors are not integrated from before. However, it might be they are operating similar as a regular switch, and could be implemented as such.
Although, as could be read from previous posts above, you would need to identify the “devicetypeID” (from dummy thing name listed in PaperUI inbox). You would also need to identify which channel and idp/odp the window sensor is operating under (from SysAp monitor or using Postman software following ABB developer program).
ok, I will test this later today, if get it working, I will post an update, thx for your work and support here.
So, I collected some information about one of my window sensors:
Device: ABBXXXXXXXXX/ch0001
WindowDoor [0x0035] => 1
WindowPosition [0x0029] => 100% <=== Open
WindowPosition [0x0029] => 0% <=== Closed
0x0035: PID_WindowDoorSensor
0x0029: PID_WindowDoorPosition
Then I created a freeathome.things file:
Bridge freeathome:bridge:mybridge [host="192.168.178.xxx", port="5280", login="openhab", password="<password>", dummy_things_enabled="true"] {
Thing freeathome:switch:ABBXXXXXXXXX_ch0001 "Fenster: Balkon links" @ "LivingRoom" [DeviceID="ABBXXXXXXXXX", ChannelId="ch0001", dataPointId="idp0000", dataPointIdUpdate="odp0000"]
}
Then I added it to my sensors.items file:
Switch LivingRoom_WindowSensor "Balkon: links"
<switch> (LivingRoom, Sensors)
{channel="freeathome:switch:ABBXXXXXXXXX_ch0001:fh_switch_channel"}
If I use the sensor and open my window I get nothing in the logs, so it is not working yet.
My problem is, I have no idea which idp/odp values are correct one and which properties I have to set.
Also I am not sure, if the device type switch is correct.
Can anyone give me a hint where and how I can get the missing information?
The values above I have found in the monitor of the access point and on page I from ABB.
Well, then you have identified the channel in use by the window sensors, i.e. ch0001.
Although, still missing some missing/required input:
-
DevicetypeID as used by the binding to create/define things. See example in Post 222. You would need to enable dummy things for your bridge in Paper UI and do a discovery: Identify your window sensor(s) from inbox, and present your result.
-
Idp/odp in use
You can identify those using the Postman software, i.e. by following the ABB development program. Alternatively, when accessing your SysAp via a web browser, enable development mode/tools. Then you can identify the websocket session, and then you’ll be able to see all events/updates occurring. Further you can screen your window sensors searching by serial, and then you can identify idp/odp.
here we go:
This part is a bit tricky. I have no access to the AAB development programm (yet), I ask about 2 years ago, but the request was rejected. I asked again for access some days ago, but no response until now.
I also had the idea to get this information from the websocket connection, but the messages are encrypted, they looks like this:
<message id="stz317355" from="mrha@busch-jaeger.de" to="installer@busch-jaeger.de" type="headline"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="http://abb.com/protocol/update_encrypted"><item id="item317354"><update xmlns="http://abb.com/protocol/update_encrypted"><data>6JSupofMvh1Zahe6GshN7fF.....iQI/bmTlCE2DAbNXWyCr+NKxCZSxjP</data></update></item></items></event></message>
Is it possible to decrypt the messages?
How does this work? Which tools or commands can I use?
Hi Frank,
I have integrated this sensor in openhab. It pretty easy. All what you need is the device ID and you have to know that channel ch0001 represents the status of the sensor.
I always look up the device ID within the free@home webinterface under device configuration. There you can see for every device the ID. It is starting with ABBXXX.
In Paper UI go in the inbox, click the plus button, select the free@home binding, click “ADD MANUALLY” at the bottom and select Switch.
Here my configuration:
@kjoglums: Do you think it is possible to extend the function for this windows sensor? In Postman I recognized 3 different states of this sensor:
0 = closed
33 = tilted
100 = opened
With the solution as describe above I get only the states closed and opened (when opened or tilted).
Then we also have the idp/odp of the window sensor open/close, i.e. idp0000/odp0000, the same as a regular switch. Which will be required for binding implementation.
@Jens_Hoffmann
As a first instance, could you try to define the window contact as a dimmer instead? It operates under the same idp/odp for open/close (on/off), but has also some additional idps/odps with default values, including an odp for percentage value (i.e. defaults at odp0001). Would assume the percentage value also could reflect window contact state.
If the window contacts operate similar as a dimmer, i.e. under same idps/odps, it will be easy to implement them for auto discovery in the binding.
Assuming you also have the window contacts recognized as “Fenster/Tür_2042”?
Great Idea. It works. The Channel “Dimmer Value” shows now the values 0% = closed, 33% = tilted and 100% = opened.
I am not sure what you mean wit "Assuming you also have the window contacts recognized as “Fenster/Tür_2042”.
Just for information the Postman output for that device:
{
"XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX": {
"devices": {
"ABB700XXXXXX": {
"channels": {
"ch0001": {
"displayName": "Fenstergriff Terrasse EG",
"functionID": "0064",
"inputs": {},
"outputs": {
"odp0000": {
"pairingID": 53,
"value": "1"
},
"odp0001": {
"pairingID": 41,
"value": "33"
}
}
}
},
"displayName": "Fenstergriff Terrasse EG",
"floor": "02",
"room": "05",
"unresponsive": false
}
}
}
}
Thanks to @Cuver77 the configuration works perfectly. I am very new to openHab, so maybe this was also a reason for my problems.
Also many thanks also to @kjoglums for your support and work on this project.
Do you plan to add the window sensors into the add-on? If yes, I would wait before configuring all my sensors and could be your tester 
With the same workaround I was able to add my motion detectors with the on/off switch and the value for the current light level. until now I have always created the motion detectors as motion detectors and now as a dimmer. The light level is at opd0002.
And the Postman output for the motion detector witout actuator:
{
"XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX": {
"devices": {
"ABB700XXXXXX": {
"channels": {
"ch0000": {
"displayName": "Bewegungsmelder",
"floor": "04",
"functionID": "0011",
"inputs": {
"idp0000": {
"pairingID": 256,
"value": "0"
}
},
"outputs": {
"odp0000": {
"pairingID": 6,
"value": "1"
},
"odp0001": {
"pairingID": 7,
"value": "1"
},
"odp0002": {
"pairingID": 1027,
"value": "15"
}
},
"room": "0F"
}
},
"displayName": "Bewegungsmelder",
"floor": "04",
"room": "0F"
}
}
}
@Jens_Hoffmann
Appreciate your Postman input and for being of great help to further develop the binding. I have updated binding code in an attempt to include the lux value under odp as you have presented for motion detectors (see download further below).
The binding should then include the new feature by default for motion detectors, meaning thingtypeid “9008”, “1008” and “9009” (as presented in Paper UI inbox) if using autodiscovery. These motion detectors would be operating under ch0000 per default, with default set features/channels:
- idp0000: Set value (on/off) for switch (it actually works forcing state change in OH)
- odp0000: Read value (on/off) for switch
- odp0002: Read value for lux
@NeoBlack
The binding code is also updated in an attempt to include Window sensors, based on above provided input.
Window sensors are introduced as a new thing selection. For autodiscovery, thingtypeid “2042” should be recognised as a window sensor. The window sensors would per default be operating under ch0001, with the following default features/channels:
- odp0000: Read value (open/closed) for contact
- odp0001: Read value for percentage
Please feel free to report any issues / non-working features.
1 Like
Sorry, missed out on a detail for the motion detector lux value. Try downloading from the link above once again.
With the updated version it works fine. Many thanks for the very fast update.
Nevertheless I have noticed few issues:
- My virtual devices from the ABB developer programm are not anymore autodiscovered. But I was still able to add them manually
- Can you please change the default value for “Id of update lux state” to opd0002. That is the right channel
- The switch of the motion detector does not turn off automatically. Same issue I had with manually added motion detectors. Maybe free@home does not send an update. Is there an option to reset the switch after few seconds? For the moment I solved the issue with a rule.
Following your numbering:
-
When you have dummy things enabled: What are your virtual switches listed as in PaperUI innox? I have “0001” for virtual devices, and these are autodiscovered.
-
That is what was corrected in my previous post, and should be corrected for the version under the download link.
-
Same for my motion detector (without actuator), no/very delayed switch off, so I am also using a rule to reset OFF.
I found a solution with a rules and an unused actor (instead of virtual switch and the developer programm/cloud API), which I put into the scene. We have no dining room, so the LivingRoom_Lamp_DinningTable thing/actor is not used at the moment.
In my case I added the actor with state ON to the “all off” scene. this actor is my trigger in my rule, if the trigger is activated, I check my windows and set the state back to OFF.
Here is my rule script:
rule "Scene: All Off"
when
Item LivingRoom_Lamp_DinningTable changed
then
// If LivingRoom_Lamp_DinningTable is triggered, Scene_All_Off was triggered
// This is a hack, because there is no event triggered to bind to
// LivingRoom_Lamp_DinningTable is a non used actor
if (LivingRoom_Lamp_DinningTable.state == ON) {
// Reset lamp state, because we want this is hack ;)
LivingRoom_Lamp_DinningTable.sendCommand(OFF)
val openWindows = newArrayList()
WindowSensors.members.forEach[item |
if (item.state == ON) {
openWindows.add(item.label)
}
]
if (openWindows.size() > 0) {
logInfo("scene.rules", openWindows.size().toString() + " open windows found")
val openWindowString = String.join(", ", openWindows).replace("Status: ", "");
logInfo("scene.rules", "I found this open windows: " + openWindowString)
// Now send a warning message via alexa
Echo_Bedroom_TTS.sendCommand('Attention, I have found some open windows: ' + openWindowString)
} else {
logInfo("scene.rules", "no open windows found")
Echo_Bedroom_TTS.sendCommand('OK, goog bye')
}
}
end
// cc @stemeda
Hey,
first of all many thanks for the work you have done so far. Most of the things are working pretty well. Unfortunately the binary sensors are not working because they are not implemented as you mentioned. How is it possible to get these running?
What information do I need to provide that they can be implemented in the binding?
The device type of the binary inputs should be “B007”. Is this the information you need?
The devicetype id “B007” will be needed and used for autodiscovery.
However, before updating the binding: As described in the posts above, we would need the channel in use, and also the idp/odp. Although, would guess a binary sensor would operate similar to a regular switch (ch0000 / idp0000 / odp0000).
So, you could test (as suggested in post #279): Create a switch manually in Paper UI (add thing --> Free@Home Binding --> add manually --> Switch). Link your thing to your bridge, input your device serial (ABB12345) for DeviceId, and keep default configuration parameters for channel, idp and odp).
If it works, we can link the binary sensor to the switch category in the binding. If not, you would need to identify the correct channel/idp/odp before we are able to implement the binary sensor in the binding.
Thanks, after a reboot autodiscovery works again. Point 2 successfully tested.
Hi,
doesn’t you have an answer to the question about the thing file?
does your binding only works with autodiscovery?
Many thanks for the whole work.
Regards