Creating things for FRITZ_DECT_300 does not work

  • Platform information:
    • Hardware: Intel 64 bit
    • OS: Debian in Docker Container: wetware/openhab
    • Java Runtime Environment:
    • openHAB version: 2.1
  • 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.

I followed the instructions here:
OpenHAB2 avmfritz Documentation

and created the things file:

Bridge avmfritz:fritzbox:arrakis [ ipAddress="", password="xxxxxxx", user="xxxxxxx" ] {
	FRITZ_DECT_300 FD300_EG_WZT [ ain = "12-digit-ain" ]
	FRITZ_DECT_300 FD300_EG_WZF [ ain="12-digit-ain" ]
	FRITZ_DECT_300 FD300_EG_K [ ain="12-digit-ain" ]
	FRITZ_DECT_300 FD300_DG_EZ [ ain="12-digit-ain" ]
	Comet_DECT CD300_OG_BZ [ ain="12-digit-ain" ]

My items file looks like this:

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.


Dear Justus,

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.

1 Like

Dear Christoph,

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:

Switch fritzDECT200Outlet "Switchable outlet" {

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 :slight_smile:


Dear Christoph,

your hint regarding the right documentation works like a charm! THANK YOU very much!!!

Find below my things and my items file for documenting the right syntax for avmfritz Thing definition in this thread:

Bridge avmfritz:fritzbox:bla [ ipAddress="", user="aaaaaa", password="bbbbbbbbbb" ] {
	Thing FRITZ_DECT_300 <12-digit-AIN-1> "FD300_1" [ ain="<12-digit-AIN-1>" ]
	Thing FRITZ_DECT_300 <12-digit-AIN-2> "FD300_2" [ ain="<12-digit-AIN-2>" ]
	Thing FRITZ_DECT_300 <12-digit-AIN-3> "FD300_3" [ ain="<12-digit-AIN-3>" ]
	Thing FRITZ_DECT_300 <12-digit-AIN-4> "FD300_4" [ ain="<12-digit-AIN-4>" ]
	Thing Comet_DECT <12-digit-AIN-5> "CD300_1" [ ain="<12-digit-AIN-5>" ]
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 :slight_smile:

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?


Hey Justus,

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. :frowning:

Hi Christoph,

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 :smiley: … I already found what is missing but need to find out how to get it into the docker container :slight_smile:.

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 …

You are welcome. I am eager to hear some feedback from AVM. Last time I wrote them they haven’t responded.

Hi Christoph,
seems that I was lucky with my request to AVM. Find below what they responded … looks promising :wink:


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 :sunglasses:

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!

Hey Justus, pretty cool. I am really excited about the upcoming new functionality.

Thanks for sharing this information.

You’re welcome :sunglasses:

Thanks for guiding me to the right setup avmfritz!

One last question to avmfritz … : AVM says that they support other DECT ULE smarthome devices (see here)

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 :wink:

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 :wink:
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. :wink: 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.

Thanks, will do!

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 :slight_smile:

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 :wink:
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 :slight_smile:

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. :smiley:

Awesome. I am excited about your findings!

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:

<device identifier="YYYYY 04XXXXX" id="407" functionbitmask="1" fwversion="00.00" manufacturer="0x2c3c" productname="HAN-FUN">
    <name>HAN-FUN #1</name>

Only name and present state are sent. Too sad. I am kind of dissapointed right now. I will give it another try tomorrow.

that’s odd :frowning: … 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 :wink: … 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?

Yes that’s right. The present tag states whether a device is reachable or not. A switch or a powermeter are represented by different tags. You can have a look at some valid results here:

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 :frowning: .
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?

Keep you posted!