Issue of the topic: I use the Bridge “thing” to connect my fritzbox to openhab2 (see things file) but the creation of the devices doe not work. Once the container starts I have to open always the Paper UI and accept (click on the blue check mark) my Fritz!DECT 300 devices as they are detected and shown in the inbox automatically but not added. My intention is to have no interaction in the Paper UI but have them added automatically.
Group gFritzSHome // Fritz Smarthome Devices
//Number istBudWasserSM "Wassertemperatur Speichermitte [%.1f °C]" (gFritzSHome) {km200="service:/system/sensors/temperatures/hotWater_t2"}
//String modeBudWasser "Mode-Warmwasserzub. [%s]" (gFritzSHome) {km200="service:/dhwCircuits/dhw1/operationMode" }
Number sollFD3CegWZTtemp "Soll Temperatur EG Terrasse [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_WZT:set_temp"}
Number aktFD3CegWZTtemp "Akt. Temperatur EG Terrasse [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_WZT:temperature"}
Switch aktFD3CegWZTbatt "Batteriestatus EG Terrasse" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_WZT:battery_low"}
Number sollFD3CegWZFtemp "Soll Temperatur EG Fenster [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_WZF:set_temp"}
Number aktFD3CegWZFtemp "Akt. Temperatur EG Fenster [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_WZF:temperature"}
Switch aktFD3CegWZFbatt "Batteriestatus EG Fenster " (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_WZF:battery_low"}
Number sollFD3CegKtemp "Soll Temperatur EG Kueche [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_K:set_temp"}
Number aktFD3CegKtemp "Akt. Temperatur EG Kueche [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_K:temperature"}
Switch aktFD3CegKbatt "Batteriestatus EG Kueche" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_EG_K:battery_low"}
Number sollCD3CogBZtemp "Soll Temperatur Bad [%.1f °C]" (gFritzSHome) {channel="avmfritz:Comet_DECT:arrakis:CD300_OG_BZ:set_temp"}
Number aktCD3CogBZtemp "Akt. Temperatur Bad [%.1f °C]" (gFritzSHome) {channel="avmfritz:Comet_DECT:arrakis:CD300_OG_BZ:temperature"}
Switch aktCD3CogBZbatt "Batteriestatus Bad" (gFritzSHome) {channel="avmfritz:Comet_DECT:arrakis:CD300_OG_BZ:battery_low"}
Number sollFD3CdgEZtemp "Soll Temperatur Dachboden [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_DG_EZ:set_temp"}
Number aktFD3CdgEZtemp "Akt. Temperatur Dachboden [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_DG_EZ:temperature"}
Switch aktFD3CdgEZbatt "Batteriestatus Dachboden" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:arrakis:FD300_DG_EZ:battery_low"}
Number sollGruppeEGtemp "Soll Temperatur EG Gruppe [%.1f °C]" (gFritzSHome)
Using this items file does not let openhab find the devices at all!
When I replaces the AIN synonyms “FD300…” with the real 12-digit AIN number then openhab at least finds them.
But in neither case they are added automatically. Only after a manual interaction in the Paper UI I start getting the values shown in the sitemap of the Basic UI. I think it is not necessary to paste the sitemap here as the problem lies in the initialization of the things resp. items.
I could live without the AIN synonyms using the AIN numbers but then I would need to know how to define the devices manually in the things file. Unfortunately there is nothing more but the Bridge definition to the fritzbox.
I hope I could explain my problem well and that someone can give a hint.
the syntax in the example of the documentation seems to be wrong. There is an ongoing discussion here. Please have a look over there and try those other examples. I am happy if you find a way which works for you and if you can give some feedback afterwards.
thank you for guiding me to the right syntax! I am currently trying it out. But I can see from your fritz.items that you also still use the AIN in the channel definition of the item:
Did you try it out whether the documentation link so wrong that it is not possible to use the name from the Thing definition or did you just “stay on the safe side” as it is ambiguous to use either the name or the AIN directly?
Secondly I am not sure if I understand whether the Thing name in the fritz.things file "AVM FRITZ!DECT 200 #1" is intentionally similar to the Frame label = "AVM FRITZ!DECT 200 #1" in the fritz.sitemap or if it is just for a better understanding?
Thank you for your support and I would be happy to completely clarify the documentation mismatch in this thread for other users as well.
I keep you posted how my installation “accepts” your definitions
Group gFritzSHome // Fritz Smarthome Devices
Number sollFD3C_1temp "Soll Temperatur 1 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-1>:set_temp"}
Number aktFD3C_1temp "Akt. Temperatur 1 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-1>:temperature"}
Switch aktFD3C_1batt "Batteriestatus 1" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-1>:battery_low"}
Number sollFD3C_2temp "Soll Temperatur 2 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-2>:set_temp"}
Number aktFD3C_2temp "Akt. Temperatur 2 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-2>:temperature"}
Switch aktFD3C_2batt "Batteriestatus 2 " (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-2>:battery_low"}
Number sollFD3C_3temp "Soll Temperatur 3 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-3>:set_temp"}
Number aktFD3C_3temp "Akt. Temperatur 3 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-3>:temperature"}
Switch aktFD3C_3batt "Batteriestatus 3" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-3>:battery_low"}
Number sollCD3C_5temp "Soll Temperatur 5 [%.1f °C]" (gFritzSHome) {channel="avmfritz:Comet_DECT:bla:<12-digit-AIN-5>:set_temp"}
Number aktCD3C_5temp "Akt. Temperatur 5 [%.1f °C]" (gFritzSHome) {channel="avmfritz:Comet_DECT:bla:<12-digit-AIN-5>:temperature"}
Switch aktCD3C_5batt "Batteriestatus 5" (gFritzSHome) {channel="avmfritz:Comet_DECT:bla:<12-digit-AIN-5>:battery_low"}
Number sollFD3C_4temp "Soll Temperatur 4 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-4>:set_temp"}
Number aktFD3C_4temp "Akt. Temperatur 4 [%.1f °C]" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-4>:temperature"}
Switch aktFD3C_4batt "Batteriestatus 4" (gFritzSHome) {channel="avmfritz:FRITZ_DECT_300:bla:<12-digit-AIN-4>:battery_low"}
I will keep the AINs in the items file as it does not matter whether I have to put the AIN or a name into that definition.
Just would be interested if it can also be the name … Thinking about that … probably in the things file where you defined the AIN in the [ ] brackets … probably you may define your own AIN … which might be also a name and then use this name in the items file … but just square thinking
One offtopic question to you: Are you happy with the battery information as a switch item?
In the Fritzbox UI it show percentage of the battery status. I would prefer that over the High/low switch …
Do you have a hint for this as well?
I am glad you got it working. I will give a textual configuration without AIN as Thing name another try.
I am not sure if I understand whether the Thing name in the fritz.things file “AVM FRITZ!DECT 200 #1” is intentionally similar to the Frame label = “AVM FRITZ!DECT 200 #1” in the fritz.sitemap or if it is just for a better understanding?
The two values have no connection. You can choose completely different values for the Thing name and the label of a sitemap.
Are you happy with the battery information as a switch item?
No, I am not. I would love to have a percentage value as well. But sadly the FRITZ! AHA interface only provides a 0 or an 1 to us.
thanks for responding to my questions. I have to postpone my tests regarding the “AIN as a Thing” configuration as I am struggeling with another issue (in a different post). I want to use openhab in a docker image but my heating binding requires a special Java extension.
Hence I can currently not talk to my heating … just for your info - not expecting a response … I already found what is missing but need to find out how to get it into the docker container .
Regarding the battery percentage view, I have sent a request to AVM (Probably not the first one ;-.) … hoping to get a useful response … keep you posted …
Hi Christoph,
seems that I was lucky with my request to AVM. Find below what they responded … looks promising
...
vielen Dank für Ihre Anfrage.
Es ist bisher nicht Ziel der AVM-Entwicklung jede Funktion der GUI auch in einer API abzubilden. Insofern ist die AHA-Dokumentation aktuell vollständig.
Wir könnten uns aber durchaus vorstellen, dass in einem nächsten Release von FRITZ!OS (~Q1-2/18) die Batterieladung auch in % über die Schnittstelle ermittelbar ist.
...
As you are they owner of the avmfritz binding, it should be interesting for you to know
Btw. … I also submitted a request to allow individual temperatures per heating interval. This is also still pending. As the temperature feeling in the morning and in the evening is much more sensitive as during the day I would like to have in the morning and in the evening the heating to be a bit warmer than during the day … AVM acknowledged that but did not yet respond when to implement it … keep you posted!
Could your binding be enhanced to support these 3rd party devices as well and what would you need to include them. I assume that you would need the definitions given in a documentation like the AVM “AHA HTTP Interface”. I am thinking about the Telekom (quivicon) optical door/windows sensor or the wall thermostat. I would offer to support in the research for the documentation but I am no programmer
Yes, I heard about that. But I have forgotten it shortly afterwards, because there was no official announcement from AVM.
I of course would say that it is possible to extend the binding for the use of third party devices. I am highly interested in doing it because it will increase the possibilities of this binding a lot. The question is, which data of those devices are accessible via the AHA HTTP Interface. As you already noticed AVM didn’t pay much attention on every data to be available in the interface. I hope they will do a lot more work on the interface in the future. I assume we currently only have the choice to do some kind of try & error or reverse engineering to find out what is possible an what is not.
I am personally not very interested in those 3rd party devices offered by Telekom. Kind of expensive. Maybe the Magenta SmartHome Wandtaster or the Magenta SmartHome Zwischenstecker (innen). But if you are willing to buy and test others, I offer you to help with implementing those features. I expect a cooperation with you will work very well. But I have to mention, that I cannot guarantee for anything. Wdyt?
Just as a side note: I am currently working on integrating the group features in the avmfritz binding. If you like to help testing them, please tell me.
Are there other DECT ULE devices that are better suited for avmfritz and/or less expensive? I assume that you would not invest in building the avmfritz binding if you would not be convinced of this approach and my guess is that AVM will not be able to build an own holistic offering of smarthome devices but will be working with partners. What do you think?
And thank you for your offer to help you testing the group features. Generally I would be happy to support you but I am currently still fighting with my move from an inofficial openhab docker container with openhab 2.1.0 and Java 1.8.0_45 to the official openhab docker container with openhab 2.2.0 and Java 1.8.0_144.
I have so much trouble to get my environment back up and running stable that I fear that another variable blows my mind
I have currently only a simple number 3 groups with 5 Fritz!Dect 300 devices so it might be easy.
If it is not too much difference I am happy to try but be patient with my response (at least until I get sendMail back “up and running”).
As I already said: I didn’t spend much time investigating the possibilities of DECT ULE for FRITZ!Box. You pointed me into this direction again. But that doesn’t mean I am not interested or doesn’t see a future for such an approach. Don’t misunderstand me. Indeed, I am a big fan of combining things. Why should I have to buy a different control unit - again and again - only because I want to exchange one of my devices with another one from a different manufacturer. That is currently the truth in smarthome. The way for AVM to work with several partners should be the way to go for them. But that’s not my decision.
One of my motivations to develop for ESH/OH2 is to build - to help building - such a common base. One basic framework for every requirement one can imagine. It makes me very happy to work together with all those great peoples of this community. I can use my personal skills to help others to reach their goals and build their own smarthome.
Long story, short meaning.
Give me ideas, solutions, whatever, and it doesn’t matter if it’s today or tomorrow or in some weeks. I am eager to help. I keep you updated when making progress with the avmfritz binding. You can give me feedback or ask questions any time.
Btw. I fixed in the meantime my sendMail issue (stupid: missed the entry in addon.cfg). Hence I am free to help you testing the groups if you like
And please do not understand me wrong as well. It is great that you leverage your personal skills to build such great stuff!!! I admire such capabilities! And I completely support your perspective to prevent having a lot of different control units. You are right that the Telekom/Quivicon devices are not cheap but I did not yet find any others
Sorry that I have to reply through this thread … but I did not manage to answer your push message in the browser … I saw it but I do not know how to respond the same way … I am unfortunately more the consumer than the programmer
It looks like that I am lucky. A colleague of mine uses Telekom products at his place. Beside several Homematic devices he owns a DECT ULE outlet like the one linked above. He will borrow it to me over the weekend. I will do some tests in my environment and with the binding.
I gave it a first try. The outlet connected to my FRITZ!Box 7490 (FRITZ!OS 6.90) without any problems. But I neither couldn’t see any data (power consumption, etc. - the device is capable of that) in the SmartHome subpage nor was it possible to switch the outlet on or off. I even wasn’t able to configure any connections or combinations like described in the linked article. The response of the AHA interface for it looks like this:
Hi,
that’s odd … I kindly appreciate your enthusiasm!!! The article looks like if the devices can not only be attached but also work. It is ugly that it does not work as expected …
The attribute “present” just means that it is attached, right?
And there should be another attribute like “status” for “OPEN” (==1) and “CLOSE” (==0), right?
Sorry for asking such stupid questions … Is there any way of tracing the traffic meaning to see what the device is sending out to the fritzbox?
If you like I can take the part to send a support request to AVM. The Hotline is available tomorrow from 10-18:00 Uhr … They know me already very well, hence I can try to call AVM support … to take away some action from you!
Any kind if help is very much appreciated. Just ask as much as you like.
The attribute “present” just means that it is attached, right?
And there should be another attribute like “status” for “OPEN” (==1) and “CLOSE” (==0), right?
I called AVM support but as expected they said that they need to pass this to their developers and that for other devices than from AVM there is currently only an “as-is” support .
I will send them your output of the HTTP interface and ask them if there is anything from their side that needs to be done to make the tags from HAN-FUN devices useable with fritz!OS …
They want to know the name of the device … is it the Quivicon or is it the Telekom device?
Do you have a link?
… I already found what is missing but need to find out how to get it into the docker container 
… I kindly appreciate your enthusiasm!!! The article looks like if the devices can not only be attached but also work. It is ugly that it does not work as expected …