Creating things for FRITZ_DECT_300 does not work

Can it be that the device needs somehow to be initialized to reveal the status tag?
Do you see it in the Fritzbox menu or do you just get info from the AHA HTTP Interface?

As there is a pairing process with the Fritz!DECT devices as well, where you have to initiate the binding on both sides followed by the confirmation with the appropriate symbols on both sides, it has to be accomplished for this device as well

Of course I assume that you have doen that with that device but you did not tell if the pairing process was successful and how this is acknowledged on device and Fritzbox side … I would assume that you should at least see the door sensor somehow in the Smart Home devices list in the Fritzbox GUI …???

Would you mind to share your findings of this? This might help if AVM comes back with a response to my support request :wink:

Did I bother you with my questions? Or did you have a breakthrough … or just simply better things to do over the weekend :slight_smile: ? I am just starting with this and trying to contribute on my level … :blush:

Some more information:

Yesterday there was an update of the FRITZ!OS available. I am now using version 6.92.

I am using the SmartHome Zwischenstecker innen - provided by Telekom.

I tried to connect the device with a FRITZ!DECT Repeater 100 connected and another time without the DECT Repeater connected. Both trials results in the same. The pairing process worked like this: plug in the device - press the button on the device for 5s - press the “Add new device” button in the FRITZ!OS GUI - search window popped up and after some seconds it changed to success.

Switching the device itself using the hardware button works like a charm. Nothing changes in FRITZ!OS GUI or AHA interface.

Here are some screenshots of what can be seen in the SmartHome section of FRITZ!OS GUI - a little bit cut to size.

Overview:

Detail view after pressing the “Edit” button:
smarthome_zwischenstecker02

I tried to add the HAN-FUN device to a group as well. But it wasn’t listed as an option under available devices.

No, of course not. Everything is fine. Some quality time with my family yesterday. :slight_smile:

Thought so. And family is definitely more important :smiley:

Ok, I guess you see the status change in the device it self but as said nothing happens in GUI or AHA HTTP interface. I would assume that no change in the GUI might be reasonable as there is no column for this special attribute “OPEN/CLOSE” but I would have at least expected that the HTTP interface should have spit something out …

Oops, I just yet checked the link you gave … you did not try the door sensor but the power plug … in this case I would have expected that it could have been rudimentary recognized …

I have prepared an email to ACM support and if you like I can shoot it off. My feeling is that they won’t really pick this special case up but give either some general advice how to tweak the interface to make it more chatty or they will simply state that it depends on the quality of the device protocol and then we will be directed to Telekom …

Look what I have found regarding AVM and HAN-FUN devices …

https://www.ip-phone-forum.de/threads/avm-wird-smart-home-standard-han-fun-in-fritz-boxen-integrieren.290672/page-12

This thread is up to date … last entry today …

So it seems that there are quite some enthusiasts and they are all keen on getting this to run …
I am excited what AVM will comment. I would suspect that they struggle to keep up with then HAN-FUN versions as this seems to be very vivid …

Nice find. I will read through it when I find some free minutes.

I am going to give the outlet back to my colleague tomorrow.

Hi,

I tried out the radiator_mode tag for the Fritz!DECT 300 thermostat and I receive three different types of status from my five devices and the status UNKNOWN causes Java errors in the openhab.log:

  1. 3 devices (Fritz!DECT 300) have status “UNKNOWN” == seems to be an error
  2. 1 device (Fritz!DECT 300) has status “COMFORT” == as expected
  3. 1 device (Comet_DECT) hast status “-” == don’t know what this means :slight_smile:

The Java errors in the openhab.log are related to the Fritz!DECT 300 devices and look like this:

20:22:27.434 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value 'UNKNOWN' of item aktFD3CegWZFmode with format '%s]: [ %s ': {}
java.util.MissingFormatArgumentException: Format specifier '%s'
	at java.util.Formatter.format(Formatter.java:2519) [?:?]
	at java.util.Formatter.format(Formatter.java:2455) [?:?]
	at java.lang.String.format(String.java:2940) [?:?]
	at org.eclipse.smarthome.core.library.types.StringType.format(StringType.java:50) [98:org.eclipse.smarthome.core:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getLabel(ItemUIRegistryImpl.java:365) [137:org.eclipse.smarthome.ui:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.render.AbstractWidgetRenderer.preprocessSnippet(AbstractWidgetRenderer.java:113) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.render.TextRenderer.renderWidget(TextRenderer.java:37) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:167) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:132) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:153) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:95) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.smarthome.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:172) [187:org.eclipse.smarthome.ui.basic:0.9.0.201710240931]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) [85:org.eclipse.jetty.servlet:9.3.14.v20161028]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [85:org.eclipse.jetty.servlet:9.3.14.v20161028]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [171:org.ops4j.pax.web.pax-web-jetty:6.0.6]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [82:org.eclipse.jetty.security:9.3.14.v20161028]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [171:org.ops4j.pax.web.pax-web-jetty:6.0.6]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [85:org.eclipse.jetty.servlet:9.3.14.v20161028]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [171:org.ops4j.pax.web.pax-web-jetty:6.0.6]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.server.Server.handle(Server.java:534) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [84:org.eclipse.jetty.server:9.3.14.v20161028]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [76:org.eclipse.jetty.io:9.3.14.v20161028]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [76:org.eclipse.jetty.io:9.3.14.v20161028]
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [76:org.eclipse.jetty.io:9.3.14.v20161028]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [87:org.eclipse.jetty.util:9.3.14.v20161028]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [87:org.eclipse.jetty.util:9.3.14.v20161028]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [87:org.eclipse.jetty.util:9.3.14.v20161028]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [87:org.eclipse.jetty.util:9.3.14.v20161028]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [87:org.eclipse.jetty.util:9.3.14.v20161028]
	at java.lang.Thread.run(Thread.java:748) [?:?]

For the one Comet_DECT device the errors in openhab.log look like:

20:59:32.373 [ERROR] [.ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Text
20:59:32.374 [ERROR] [.ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'aktCD3CogBZmode' for widget org.eclipse.smarthome.model.sitemap.Text
20:59:32.375 [ERROR] [.ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'aktCD3CogBZmode' for widget org.eclipse.smarthome.model.sitemap.Text
20:59:32.375 [ERROR] [.ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'aktCD3CogBZmode' for widget org.eclipse.smarthome.model.sitemap.Text

In your Github repository is documented that the radiator_mode is supported for all of these devices. All have the latest firmware level: 4.36 for the Fritz!DECT 300 and 3.68 for the Comet_DECT

https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.avmfritz

Any idea what’s going on here?

P.S.: I have shot the email to AVM regarding the HAN-FUN sensor … let you know what they reply …

Any idea what’s going on here?

Yes, I think so. The value “UNKNOWN” is a valid state for the radiator_mode channel. I didn’t mention it in the documentation. It will be returned if the internal logic couldn’t determine the current mode. I will post a link to the used logic later. I assume you use a transformation to format/translate the states of the radiator_mode channels. The error in the logs maybe results from a missing entry in your transformation file.

Can you please post your item definition for the device which has the “-” state? Without knowing anything about it I would tend to a syntax error in that definition.

Here is the link to the calculation of the logic: https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.avmfritz/src/main/java/org/openhab/binding/avmfritz/internal/ahamodel/HeatingModel.java#L93
I guess there is a mistake in it. The state “UNKNOWN” is set whenever no matching temperature can be found. It could be discussed if the last else has to be changed to return MODE_ON instead. Wdyt?

P.S.: I have shot the email to AVM regarding the HAN-FUN sensor … let you know what they reply …

Thank you very much. I can’t wait to hear their answer.

No, I am currently simply reading the state and publishing it on my sitemap to see what the state is:

Part of the default.sitemap:

   Frame label="Erdgeschoss" {
   	        // geändert
	    	Text item=aktFD3CegWZTtemp label="Akt. Temp. EG-T [%.1f °C]" icon="temperature"
        Text	item=aktFD3CegWZTmode label="Modus von EG-T: [%s]" icon="radiator"

	   		Text item=aktFD3CegWZFtemp label="Akt. Temp. EG-F [%.1f °C]" icon="temperature"
        Text item=aktFD3CegWZFmode label="Modus von EG-F [%s]:" icon="radiator"

	   		Text item=aktFD3CegKtemp label="Akt. Temp. EG-K [%.1f °C]" icon="temperature"
        Text item=aktFD3CegKmode label="Modus von EG-K: [%s]" icon="radiator"
	   	}

Find below the items file for all devices as ou might need it for the “UNKNOWN” problem as well. The first three have the problem. The 4th is the Comet_DECT and the last works ok:

Number	sollFD3CegWZTtemp		"Soll Temperatur EG Terrasse [%.1f °C]"	 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:AAAAAAAAAAAA:set_temp"}
Number	 aktFD3CegWZTtemp		"Akt. Temperatur EG Terrasse [%.1f °C]"	 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:AAAAAAAAAAAA:temperature"}
Switch	 aktFD3CegWZTbatt		"Batteriestatus EG Terrasse"			       (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:AAAAAAAAAAAA:battery_low"}
String   aktFD3CegWZTmode   "Thermostat Modus EG Terasse [ %s ]" 		 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:AAAAAAAAAAAA:radiator_mode"}

Number	sollFD3CegWZFtemp		"Soll Temperatur EG Fenster [%.1f °C]"	 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:BBBBBBBBBBBB:set_temp"}
Number	 aktFD3CegWZFtemp		"Akt. Temperatur EG Fenster [%.1f °C]"	 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:BBBBBBBBBBBB:temperature"}
Switch	 aktFD3CegWZFbatt		"Batteriestatus EG Fenster "			       (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:BBBBBBBBBBBB:battery_low"}
String   aktFD3CegWZFmode   "Thermostat Modus EG Fenster [ %s ]" 		 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:BBBBBBBBBBBB:radiator_mode"}

Number	sollFD3CegKtemp			"Soll Temperatur EG Kueche [%.1f °C]"	   (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:CCCCCCCCCCCC:set_temp"}
Number	 aktFD3CegKtemp			"Akt. Temperatur EG Kueche [%.1f °C]"	   (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:CCCCCCCCCCCC:temperature"}
Switch	 aktFD3CegKbatt			"Batteriestatus EG Kueche"				       (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:CCCCCCCCCCCC:battery_low"}
String   aktFD3CegKmode     "Thermostat Modus EG Küche [ %s ]" 			 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:CCCCCCCCCCCC:radiator_mode"}

Number	sollCD3CogBZtemp		"Soll Temperatur OG Bad [%.1f °C]"			 (gFritzSHome)	{channel="avmfritz:Comet_DECT:arrakis:DDDDDDDDDDDD:set_temp"}
Number	 aktCD3CogBZtemp		"Akt. Temperatur OG Bad [%.1f °C]"			 (gFritzSHome)	{channel="avmfritz:Comet_DECT:arrakis:DDDDDDDDDDDD:temperature"}
Switch	 aktCD3CogBZbatt		"Batteriestatus OG Bad"					         (gFritzSHome)	{channel="avmfritz:Comet_DECT:arrakis:DDDDDDDDDDDD:battery_low"}
String   aktFD3CogBZmode    "Thermostat Modus OG Bad [ %s ]" 			   (gFritzSHome)	{channel="avmfritz:Comet_DECT:arrakis:DDDDDDDDDDDD:radiator_mode"}

Number	sollFD3CdgEZtemp		"Soll Temperatur Dachboden [%.1f °C]"	   (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:EEEEEEEEEEEE:set_temp"}
Number	 aktFD3CdgEZtemp		"Akt. Temperatur Dachboden [%.1f °C]"	   (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:EEEEEEEEEEEE:temperature"}
Switch	 aktFD3CdgEZbatt		"Batteriestatus Dachboden"				       (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:EEEEEEEEEEEE:battery_low"}
String   aktFD3CdgEZmode    "Thermostat Modus Dachboden [ %s ]" 		 (gFritzSHome)	{channel="avmfritz:FRITZ_DECT_300:arrakis:EEEEEEEEEEEE:radiator_mode"}

Remove the last colon (“:”) after the square brackets.

Should be, shouldn’t it (aktCD3... instead of aktFB3...)?

String   aktCD3CogBZmode    "Thermostat Modus OG Bad [ %s ]" 			   (gFritzSHome)	{channel="avmfritz:Comet_DECT:arrakis:DDDDDDDDDDDD:radiator_mode"}

Alread found that myself while posting :slight_smile:
Changed the state in the sitemap from “Err” to “UNKNOWN”.

You already got the corrected screenshot …

I agree. I have currently issues with the temperature as when the thermostat opens the temperature of my heating seems to be so high that the temperature near the radiator increase so high that the thermostat jumps to over 25 °C even though the room temperature is still moderate around 22 °C so maybe it really does not find the right temperature as is its beyond the configured values and hence it would be appropriate to set the mode to “ON” as this only occurs while the heating raises the temperature … Wdyt? :wink:

Damned “Cut & Paste” error !!! [ SOLVED ] Awesome! thx!
Thanks for looking better than me :eyeglasses: :stuck_out_tongue:

21:31:32.670 [INFO ] [smarthome.event.ItemStateChangedEvent] - aktCD3CogBZmode changed from NULL to COMFORT

In the other two rooms there is only one thermostat and much more space around the thermostat so that the hot water in the radiator seems not to affect the temperature measurement of the thermostat … I will try to reduce the water temperature of my heating …

You are welcome. It’s my job to find such things. :wink:

I will prepare a PR in the next few days. Found another bug on the way which has to be solved, too.

And I like to introduce a new feature. The “BOOST” mode is stolen from other manufacturers. They set the maximum temperature for a fixed duration - 5 min - and switch back to the previous temperature after that. I like to have that business logic in the avmfritz binding as well.

Small spaces around temperature sensors are cruel for automation. I myself have some FRITZ!DECT 200 devices behind the washing machine or the refrigerator. Both devices show very high temperatures, which doesn’t match to the real room temperature. I have to skip them for any rules or calculations in my whole setup. Every sample has its spikes.

That is why got myself a zwave temperature sensor to measure somewhere in the center of the room. The difficulty and the difference to your Fritz!DECT 200 is that the sensor of the Fritz!DECT 300 are coupled with the actor and hence it acts depending on the temperature measured … It would be better to decouple and allow steering from outside … I am currently trying to find out how to do that as my current heating model is either hot or cold which is not highly appreciated by my family …

Thanks for updating your binding. To know in which mode the thermostat is helps a lot to figure out how to steer it from the outside.
The Netatmo actors also provide the information about when and how long the valve is set open this is also helpful and in my opinion also important to balance the temperature leveling but it seems that there is nothing like that in the AVM thermostats …

Anyways … step by step … and I kindly appreciate your great support !!!

Just to let you know … once the devices are in a “normal” mode they show the appropriate radiator_mode :slight_smile:

1 Like

Hope to find the time this weekend. As I also submitted an change request for the alpine based docker container which has been implemented … I have to be careful not to change too much at a time :slight_smile:

Find below the response from AVM regarding your HAN-FUN test … Very good news is that they do not generally push it off the table with some superficial excuse and indifferent outlook but they want to understand how you did it and to collect data to support you …

We must now find a way to switch to you and if your friend might borrow you his outlet again than you may provide the data … see quote of the email below:

vielen Dank für Ihre Anfrage an den AVM Support. Es tut mir leid, dass die Einbindung Ihres Telekom Smart Home Gerätes nicht funktioniert.

Eine Kompatibilitätsliste liegt uns im Rahmen des AVM-Supports derzeit nicht vor, da die Entwicklung bezüglich Anpassungen für zukünftige FRITZ!OS-Updates noch nicht abgeschlossen ist.

Gerne schauen wir uns das von Ihnen beschriebene Fehlerbild jedoch genauer an, um hier eine Analyse bezüglich der Ursache vorzunehmen.

Dazu benötige ich noch folgende Informationen von Ihnen:

Wie genau sind Sie beim Anmeldeversuch der Smart Home Zwischenstecker an Ihrer FRITZ!Box 7590 vorgegangen?

Erstellen Sie bitte auch die Support-Daten Ihrer FRITZ!Box möglichst während oder unmittelbar nach Auftreten des Fehlers. Die Vorgehensweise ist unter folgendem Link beschrieben:

Support-Daten der FRITZ!Box erstellen

Senden Sie mir bitte anschließend die Fehlerbeschreibung und das ZIP-Archiv mit den Support-Daten zu.

I do not know if you can describe all the steps in detail again after one week :wink: and if it makes sense to collect the data one week later … If you think it is feasible than I would suggest that you create an own support ticket referencing to mine while I reference my ticket to yours to keep AVM with their promise to support :slight_smile:

But if you decide to drop it for now and - knowing that AVM is positive to support - open your own ticket at a later convenient time for you - when you are able to rerun the tests - then I will tell AVM that the outlet was borrowed and that we will pursue this later again.

Sorry, I can not continue as now your environment and expertise is needed … let me know how you want to proceed!

That’s cool. Can you PM me the link behind the following section of the email? It got lost in your post. I will try to create the requested log file.

Do you have a ticket number for me which I can refer to from my own support case?

I did some research in the above linked external thread. There are three HAN-FUN devices, which are working in combination with a FRITZ!Box. That is confirmed by the community over there. I don’t have access to them.

  • Rauchmelder (smoke detector)
  • Tür-/Fensterkontakt optisch (door/window sensor)
  • Wandtaster (wall switch)

I reconsidered my tests. It maybe doesn’t make sense to use a HAN-FUN outlet provided by Telekom at the moment. The DECT200 is cheaper and capable of measuring the temperature beside measuring power and energy. The later ones are supported by the Telekom device as well. Additionally it is possible to toggle the AVM devices by clapping in you hands.

1 Like