FRITZ!DECT 400 Support?

Add-ons Bindings
21

I’d wish I could give you positive feedback, but I can’t. No progress yet. Sry.

1 Like
22

@cweitkamp Did you looked into the problem with the XML structure again? :slightly_smiling_face: Is there otherwise something we can ask AVM to also implement in their API to make the openHAB implementation easier?

23

Screenshot_20190722-184252
Screenshot_20190722-184252.png1440×2880 143 KB

theres no support even in my fritz app. I’d like to control hue lights via openhab and bought this switch for. just wasted 30 euros.
hopefully they’ll support this device soon

24

Who do you mean? AVM themselves or us?

If you addressed me then I have to disappoint you one more time. Currently I put no high priority on this because I expect no really good user experience with it after the integration. We have to keep in mind that the avmfritz binding has to use a polling strategy to get the data which obviously will lead to gaps between the moment you will press the button and the related event triggering in openHAB.

25

Hi,
sorry for the late answer. With “them” I meant AVM. I wouldn´t ever push a developer working in his leisure hours…

When I wrote my comment I assumed that the protocol doesn´t contain the information but I read the thread again and found out it does now…

I understand that polling is not a good choice for this (more for gathering data). Is it possible to set a polling interval of 500ms or 1000ms only for the switches? I wouldn´t mind that time as long as the switch operates at all.

OT: Are there any nice out-of-the-box switches for use with openhab?

Many thanks for your work!

26

Depends a bit on what you are already using in your setup:

  • homematic:
    • needs a bridge (ccu) (raspy hw modul and open source software can simulate that bridge)
    • longer range than bluetooth / zigbee
    • variety of different buttons (2in1, 6in1, …)
    • design wise a bit dated
    • batteries needed
    • reliable (for me)
  • Hue / zigbee
    • bridge / zigbee usb stick needed
    • sleeker design
    • shorter range but pluged-in devices mesh enabled (aka pluged-in lights)
    • batteries needed
    • reliability / compatibility with openHAB: no idea, I’m not using them
  • Tradfri (Ikea) - also zigbee
    • same as for Hue (Philips)
    • the Tradfri binding isn’t properly working since more than half a year…
  • Logitech Pop
    • never got them to properly work with openHAB
  • bluetooth low energy battery less buttons
    • @pfink was showing some from EnOcean during the berlin meetup in January
    • interesting concept, but as far as I got him:
      • low range
      • no mesh
      • poor openHAB integration

Probably many more :thinking:

27

:sweat: Lucky me. You are welcome.

No, I am afraid not. There is only one global endpoint to poll which delivers everything. The AVM switch is usable but only in combination with their own devices / outlets / new bulb.

I am addicted to Zigbee stuff… Using TRADFRI remotes, Hue remotes, Busch-Jaeger wall-mounted switches via deCONZ.

1 Like
28

Hi,

I’d be interested in this also. Especially when the Fritz!DECT 440 with temperature sensor and 4 buttons arrives in Q2/20.

As per the delay on switching things … yes … that is noticable. I have one Magenta Switch (lucky me, that I didn’t like the looks of the AVM one and bought the Magenta one) and it works. I can switch a Hue Bulb on and off with it, but it takes a few seconds, where as it is pretty much instant within the AVM eco system.

A bit of a shame, but never the less, thanks for the effort.

I have had a bit bad experience with the Trådfri remotes (on my Hue Bridge), so I’m steering clear of those. Need to get a Phillips one to test.

I have both Phillips and Ikea Zigbee smart bulbs, but also Magenta HAN-FUN smart bulbs (Fritz!OS 7.19-labor, Fritz!Box 7590). The latter which also is not discovered in the OpenHAB binding currently.

Anything Zigbee is on my Phillips Hue Hub, as I didn’t like the way Ikeas Hub works.

/M

29

Hi all,

I have some news. After some refactoring in the latest OH version (2.5.5) of the avmfritz binding I took another look into this. I now finalized the FRITZ!DECT 400 integration. You can find a test version linked in my PR:

30

@cweitkamp,

thank you for adding FRITZ!DECT 400 support to the binding.

I tried the test version available in the PR and have the issue that pressing the button once triggers my rule containing the following event trigger three times:

Channel "avmfritz:FRITZ_DECT_400:1:xxxxxxxxxxxxxxx:press" triggered SHORT_PRESSED

Please note that I am using the bridge option pollingInterval=“5” instead of the standard 15 seconds polling interval. The duration between the three repeated rule trigger events is actually 5 seconds.

31

@Alex5719 Thank you for giving feedback.

Before triggering the event on the channel I check the lastPressedTimestamp from FRITZ!Box against a 15 seconds offset (see code). If your pollingInterval is less than 15s it might happen that the event will be published more than once. As the minimum valid value for pollingInterval is 5s I should reduce my offset to something smaller …

32

@cweitkamp Thanks for addressing my issue.

I have now installed the latest PR build and can confirm that the problem with the multiple trigger events is resolved. But I now have the new problem pressing the DECT push-button does not reliable triggers my rule. Sometimes it works and sometimes not. Nevertheless the last_change channel is reliable updated but maybe the update takes slightly more than the newly introduced 3 seconds offset. Maybe the quality of the radio connection of my DECT push-button is not the best and I also have a Mesh network active that might slow down things.

As a workaround I would suggest to set the offset to pollingInterval-1. In this way I could choose a slightly longer polling interval to get around my timing problems.

Or it would be even better to not rely on a time constant but identify wether the last identified press event has already been sent to the OpenHAB event bus and only send events that have not been sent before.

33

Your testing is very much appreciated and helpful. I will rethink the way how to determine if an event should be emitted or not. Maybe I have to store the last timestamp internally to compare against it. I keep you posted.

34

I pushed a new version which Introduces a separate handler for buttons and stores the last pressed timestamp internally. Do you like to try it? You maybe have to restart openHAB or recreate the FRITZ!DECT 400 Thing because it now has a new handler.

1 Like
35

@cweitkamp I have tested the new binding binary from https://github.com/openhab/openhab-addons/pull/7817 and can confirm that the FRITZ!DECT 400 push-button events are now reliable triggering rules for both triggers:

Channel "avmfritz:FRITZ_DECT_400:1:xxxxxxxxxxxxxxx:press" triggered SHORT_PRESSED
Channel "avmfritz:FRITZ_DECT_400:1:xxxxxxxxxxxxxxx:press" triggered LONG_PRESSED

Thank you for implementing FRITZ!DECT 400 support and fixing my issues.

1 Like
36

Cool. I am happy about the results. Thanks for your support :+1:.

1 Like
37

Awesome - This is the best and simplest solution (if Fritzbox is already available in your home) - No additional bridge needed, long battery life (I hope) more reliable than a Wifi solution. It’ll serve as some sort of panic button for my grandma.

Thank you

38

Dear all,

Does anyone know if the DECT 440 4way button might already be supported or if it is planned to be integrated?

Thanks a lot!
Christian

39

Hi Christian,

The device is not yet supported. But definitely in planning. Still waiting for a user who can send me some DEBUG / TRACE logs of avmfritz binding and a F!D 440 paired with his F!Box. After that I hope we can integrate it quickly.

1 Like
40

Glad to hear, thank you!
Might buy one and start testing. If it helps and I have some free time, trying to collect such info. Let me go ahead and buy one piece of them :slight_smile:

Best wishes,
Christian