The future of AVM (fritzbox, fritzaha) bindings

[Robert Bausdorf]

Hi all,

Shortly I ported the 1.x fritzaha binding to OH2. This binding supports AVM AHA (AVM Home Automation) devices as things. These things depend on a FRITZ!Box as bridge - so you will always find the FB in your setup. So far - so good.

Yesterday I took a deeper look into the 1.x fritzbox binding with the intention to port it too. The binding currently supports

• Switch on/off DECT
• Switch on/off WIFI
• Switch on/off guest WIFI
• Switch on/off the default answering machine (newer firmware supports more than one)
• Get inbound, outbound and active call events.

The binding - as it currently is - depends on an enabled telnet within the fritzbox for the switching parts. This is not enabled by default and enabling it is some kind of a "hacking"-feature. The Methods/Commands the existing binding uses to switch things on/off might be changed by AVM without notice. The signalling part for call numbers is ok - it depends on the call monitor port which is used by other AVM and 3rd party software.

My Ideas - which I whish to discuss - are as follows:

• Incorporate the "old" fritzbox binding features as channels supported by the OH2 FB bridge in the 2.x fritzaha binding
• Change the access methods for the switching part to TR-064 protocol

Especially switching to TR-064 has some benefit:

• Well documented interfaces
• Changes to the API will be announced
• Supported channel features are discoverable - therefore reduced model/feature dependencies :-)
• Much more channel features possible :-D

I've forked and prepared a client lib I would use for the port.

So what do you think of this ?

What features supported by  TR-064 protocol would make sense to provide as channels ?

Cheers - Robert

[Kai Kreuzer]

Hi Robert,

These things depend on a FRITZ!Box as bridge - so you will always find the FB in your setup.

Not for the 546E, which can be used standalone. But it runs a kind of downstripped FritzOS, so possibly it supports TR064 as well?

The binding - as it currently is - depends on an enabled telnet within the fritzbox for the switching parts.

Are you aware of the recent pull request https://github.com/openhab/openhab/pull/2494?

Do I understand you right that the HA features are also accessible through TR064?

In general, I think it is a good idea to merge these functionality into one binding - so that a FritzBox only turns up as one device and not as multiple.

I've forked and prepared a client lib I would use for the port.

I read that TR046 is based on UPnP. Would it make sense to use the existing upnp services within openHAB 2 for this (e.g. discovery, upnp actions etc.)?

Your library currently includes all dependencies in the jar. If you want to use it, it should be OSGiyfied as most of its dependencies are already available as bundles in openHAB - so no need to duplicate them.

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/dee8ff88-0127-4088-ba92-cf1f72dafbc9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Bausdorf]

Hi Kai,

Am Freitag, 24. April 2015 15:23:58 UTC+2 schrieb Kai Kreuzer:

Hi Robert,

These things depend on a FRITZ!Box as bridge - so you will always find the FB in your setup.

Not for the 546E, which can be used standalone. But it runs a kind of downstripped FritzOS, so possibly it supports TR064 as well?

Right for 546E standalone - but I dont know if the documented AHA/TR064 interfaces work on the standalone adapter. But good point - the 546E is discovered in the initial UPnP discovery. I will check if both interfaces are working ...
If so - what is the expected behaviour of OH2/ESH in case of:

• Devices (=Things) A1 and A2 are physically identical
• A Bridge B is discovered via UPnP
  
• A1 is discovered via B (ESH Discovery)
  
• A2 is discovered via UPnP

Are A1 and A2 treated identical (same instance), equal (two instances but getting the same events) or different (two instances, different events) ?

The binding - as it currently is - depends on an enabled telnet within the fritzbox for the switching parts.

Are you aware of the recent pull request https://github.com/openhab/openhab/pull/2494?

No - thanks for mention it. Will have a look ... :-)

Do I understand you right that the HA features are also accessible through TR064?

In general, I think it is a good idea to merge these functionality into one binding - so that a FritzBox only turns up as one device and not as multiple.

No - the HA features are not available trough TR064.

I've forked and prepared a client lib I would use for the port.

I read that TR046 is based on UPnP. Would it make sense to use the existing upnp services within openHAB 2 for this (e.g. discovery, upnp actions etc.)?

Your library currently includes all dependencies in the jar. If you want to use it, it should be OSGiyfied as most of its dependencies are already available as bundles in openHAB - so no need to duplicate them.

Yes, TR064 uses the UPnP communication channels. But I'm not so familiar with the common UPnP mechanism - at first glance it seems that 064 is kind of a UPnP-"Backpack". Your absolutely right about dependencies: Because of the fact that all dependencies are covered by openHAB bundles :-) my idea is to incorporate the worker code directly into the binding. The main cause of my fork of this lib was to clarify dependencies, make the XML mapping more robust, backport it to Java 1.7 source/target level (the original depends on 1.8) and to have a standalone testing tool for 064 ... ;-)
 

Best regards,

Kai

Cheers - Robert

[Kai Kreuzer]

Hi Robert,

If so - what is the expected behaviour of OH2/ESH in case of:

• Devices (=Things) A1 and A2 are physically identical
• A Bridge B is discovered via UPnP
  
• A1 is discovered via B (ESH Discovery)
  
• A2 is discovered via UPnP

Are A1 and A2 treated identical (same instance), equal (two instances but getting the same events) or different (two instances, different events) ?

I think the only feasible solution is to treat them as two different devices. As one is accessed through a bridge, it will anyhow have a different UID (as the bridge id is part of it) and technically we cannot tell whether it is the same physical device or not. In general I think this is anyhow a very rare situation.

If this situation turns up within a single binding (as it is the case here) then you might decide yourself what makes most sense for this device, e.g. you could say that you only allow UPnP discovery for 546E and do not list it when you find it on a Fritz!Box. But I am not sure if this would be valid or if users might want to always access it through the Fritz!Box…

But if there is a single device that offers different functionality through different communication channels (like the Fritz!Box through TR-064, telnet and the call-monitor-port), then it is definitely a good idea to combine this into a single binding and not have 3 of them :-)

Best regards,

Kai

[Robert Bausdorf]

Hi Kai,

I had a look at  https://github.com/openhab/openhab/pull/2494. It seems to do in general the same - the only difference is that gitbock uses Xpath and own objects to access FB responses while I use JAXB.

I think the only feasible solution is to treat them as two different devices. As one is accessed through a bridge, it will anyhow have a different UID (as the bridge id is part of it) and technically we cannot tell whether it is the same physical device or not. In general I think this is anyhow a very rare situation. 

If this situation turns up within a single binding (as it is the case here) then you might decide yourself what makes most sense for this device, e.g. you could say that you only allow UPnP discovery for 546E and do not list it when you find it on a Fritz!Box. But I am not sure if this would be valid or if users might want to always access it through the Fritz!Box…

Ahh - they get different a UID  - so we think of it as two aspects of the same thing.  

But if there is a single device that offers different functionality through different communication channels (like the Fritz!Box through TR-064, telnet and the call-monitor-port), then it is definitely a good idea to combine this into a single binding and not have 3 of them :-)

 

Then I will go ahead ... :-) 

Best regards,

Kai

[Dominic Lerbs]

Hello Robert,
any update in this? (I am coming from the discussion here: https://github.com/openhab/openhab/issues/2953)