[avmfritz] Support new devices

[andrewfg]

This PR adds support for the following new devices:

1. HAN FUN temperature and humidity sensor (requested by @cryxy). This is exposed in OH via two Things -- namely a Thing with temperature and humidity Channels, plus a Thing with battery-level and battery-low Channels

2. Fritz!DECT 350 (aka Fritz!Smart Control 350) contact sensor (requested by @clown522). This is exposed in OH via two Things -- namely a Thing with a contact-sensor Channel, plus a Thing with battery-level and battery-low Channels

Resolves #16340
Resolves #17686

Depends on #18624

The testing Jars are here

org.openhab.binding.avmfritz-SNAPSHOT.zip

Awaiting tests/confirmation from:

• @cryxy concerning the battery-low resp. battery-level functionality
• @clown522 concerning the DECT 350 contact sensor functionality in general

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

[andrewfg]

Both channels are null. It appears that all zigbee devices are splited into two or more device elements. The element that contains the temperature and humidity does not contain the battery values.

@cryxy many thanks for the trace log. I can see from the logs, (and from the API specification), that the battery presents itself as a separate device. Whereby apparently the identifier of the one is a sub-string of the identifier of the other.

I am wondering how best to handle such cases in OH. There seems to be two possible solutions -- namely a) to have two Things in OH, one with the main sensor channels, and the other with the battery channels, or b) to try to merge the two sub-things into a common OH Thing which combines all channels in one single Thing. => WDYT?

---

EDIT to answer my own question: I think it is easier from a coding point of view to have two separate Things in OH. So just as I created a new Thing-Type for HAN-FUN Sensor, I shall also create another new Thing-Type for HAN-FUN Sensor Battery..

[andrewfg]

@clown522 I found the xml here

[andrewfg]

@clown522 / @cryxy the HAN-FUN sensors are exposed as two 'devices' as follows:

1. Functional (virtual) sensor device(s) such as contact sensors, wall switches, or power outlets (these already exist as OH Things in prior binding versions), or temperature/humidity sensors (which are new Things introduced by this PR)

2. Physical devices (Geräte) which are the "host" for functional device(s). If the physical device is battery powered then new in this PR it is exposed as a Thing with respective battery-level and battery-low channels. (By contrast mains powered physical devices are not exposed as Things since they do not need to expose any such channels).

The Fritz!DECT 350 (aka Fritz!Smart Control 350) is in fact nothing more than a HAN-FUN (battery) device; so it will appear as a physical (Gerät) device Thing with the battery channels, plus a functional sensor device Thing with the contact sensor channel.

---

EDIT @clown522 / @cryxy can you please test this and confirm? The test Jars are in the top post of this PR.

[cryxy]

@andrewfg Two different things are suitable for me. However I noticed the following during testing:

• The battery values unfortunately remain null for me.
• For bulbs that are not battery-powered, an additional “host” things is also exposed.

Here are a few more logs:

<device identifier="15282 0149774" id="25" functionbitmask="1" fwversion="03.58" manufacturer="AVM" productname="FRITZ!Smart Control 350">
	<present>1</present>
	<txbusy>0</txbusy>
		<name>Fensterkontakt</name>
		<battery>90</battery>
		<batterylow>0</batterylow>
	</device>
	<device identifier="15282 0149774-1" id="2000" functionbitmask="8208" fwversion="0.0" manufacturer="AVM" productname="FRITZ!Smart Control 350">
		<present>1</present>
		<txbusy>0</txbusy>
		<name>Fensterkontakt</name>
		<etsiunitinfo>
			<etsideviceid>25</etsideviceid>
			<unittype>514</unittype>
			<interfaces>256</interfaces>
		</etsiunitinfo>
		<alert>
			<state>0</state>
			<lastalertchgtimestamp>1746598133</lastalertchgtimestamp>
		</alert>
	</device>

<device identifier="Z90395EFFFECEBF27" id="20013" functionbitmask="1" fwversion="1.1.20" manufacturer="0x117c" productname="IKEA of Sweden TRADFRI bulb GU1">
	<present>0</present>
	<txbusy>0</txbusy>
	<name>Arbeit Licht Schreib</name>
</device>
<device identifier="Z90395EFFFECEBF2701" id="2021" functionbitmask="237572" fwversion="0.0" manufacturer="0x117c" productname="IKEA of Sweden TRADFRI bulb GU1">
	<present>0</present>
	<txbusy>0</txbusy>
	<name>Arbeit Licht Schreib</name>
	<simpleonoff>
		<state></state>
	</simpleonoff>
	<levelcontrol>
		<level></level>
		<levelpercentage></levelpercentage>
	</levelcontrol>
	<colorcontrol supported_modes="0" current_mode=""  fullcolorsupport="0" mapped="0">
		<hue></hue>
		<saturation></saturation>
		<unmapped_hue></unmapped_hue>
		<unmapped_saturation></unmapped_saturation>
		<temperature></temperature>
	</colorcontrol>
	<etsiunitinfo>
		<etsideviceid>20013</etsideviceid>
		<unittype>278</unittype>
		<interfaces>512,513,514</interfaces>
	</etsiunitinfo>
</device>

[andrewfg]

@cryxy many thanks for the testing. However 1) what you say in your report and 2) what you show in your logs seems not to be compatible with 3) the new code. Based on the logs that you posted, the new 'host' device Things should NOT be auto created in the Inbox. So I wonder if you can clarify the following:

1. the device with Id Z90395EFFFECEBF2701 should appear as a Color Light Thing (unchanged from before) => do you confirm?
2. the device with Id 152820149774_1 should appear as a Contact Sensor Thing (unchanged from before) => do you confirm?
3. the device with Id Z90395EFFFECEBF27 should NOT appear as a 'host' Thing in the Inbox => do you confirm? and/or if it does appear as a Thing, is it because you manually force created a thing with that Id?
4. the device with Id 1528201497741 should NOT appear as a 'host' Thing in the Inbox => do you confirm? and/or if it does appear as a Thing, is it because you manually force created a thing with that Id?

[andrewfg]

@cryxy I made a new build. It is in the post at the top of this PR under the same link as before. This should now allow the 'host' device to report its battery state. Nota Bene: please only use 'host' Things that are auto- detected by OH and placed in the Inbox. (Obviously you can force create a host Thing with the wrong identifier of say a light bulb, but obviously such forced things will not have any valid channel data).

[cryxy]

@andrewfg

@cryxy I made a new build. It is in the post at the top of this PR under the same link as before. This should now allow the 'host' device to report its battery state.

Thanks, all battery values are now reported. 👍

the device with Id Z90395EFFFECEBF2701 should appear as a Color Light Thing (unchanged from before) => do you confirm?

Yes, confirmed.

the device with Id 152820149774_1 should appear as a Contact Sensor Thing (unchanged from before) => do you confirm?

Yes, confirmed.

the device with Id Z90395EFFFECEBF27 should NOT appear as a 'host' Thing in the Inbox => do you confirm? and/or if it does appear as a Thing, is it because you manually force created a thing with that Id?

No unfortunately, the device with Id Z90395EFFFECEBF27 does appear in the Inbox. I did not create it manually.

the device with Id 1528201497741 should NOT appear as a 'host' Thing in the Inbox => do you confirm? and/or if it does appear as a Thing, is it because you manually force created a thing with that Id?

The device appears in the inbox. However, this is actually correct. It is battery-powered.

[andrewfg]

@cryxy many thanks for testing. It is a mystery for me why Z90395EFFFECEBF27 still appears in the inbox. Could you perhaps log:set TRACE and delete that thing and wait until it reappears and then upload the full log as a zip file?

---

EDIT: to be very specific: if the following XML (from your own log) is manually injected into the binding code, it does NOT create a HAN_FUN_HOST Thing in the Inbox. So since you do see such a Thing then I need to see the precise piece of XML that caused that.

<device identifier="Z90395EFFFECEBF27" id="20013" functionbitmask="1" fwversion="1.1.20" manufacturer="0x117c" productname="IKEA of Sweden TRADFRI bulb GU1">
	<present>0</present>
	<txbusy>0</txbusy>
	<name>Arbeit Licht Schreib</name>
</device>

[andrewfg]

@cryxy / @clown522 I found this Fritz device compatibility list and it seems to me that the OH binding covers neither the motion sensor nor the leak sensor functions (yet); but it would be trivial to add those at the same time is this PR. => so if either of you have such then please let me know.

EDIT: probably these are already supported under the category "contact sensor" ??

[cryxy]

@andrewfg

@cryxy many thanks for testing. It is a mystery for me why Z90395EFFFECEBF27 still appears in the inbox. Could you perhaps log:set TRACE and delete that thing and wait until it reappears and then upload the full log as a zip file?

After running “openhab:inbox clear” it no longer appeared. I think this was a caching issue. It is probably due to the “present” element is 0, because I have switched off the lamp in the meantime. I have another example:

<device identifier="Z001788010D4B55D3" id="6040" functionbitmask="524289" fwversion="1.116.5" manufacturer="0x100b" productname="Signify Netherlands B.V. LWG004">
	<present>1</present>
	<txbusy>0</txbusy>
	<name>Licht</name>
</device>
<device identifier="Z001788010D4B55D30B" id="2036" functionbitmask="106500" fwversion="0.0" manufacturer="0x100b" productname="Signify Netherlands B.V. LWG004">
	<present>1</present>
	<txbusy>0</txbusy>
	<name>Licht</name>
	<simpleonoff>
		<state>0</state>
	</simpleonoff>
	<levelcontrol>
		<level>255</level>
		<levelpercentage>100</levelpercentage>
	</levelcontrol>
	<etsiunitinfo>
		<etsideviceid>6040</etsideviceid>
		<unittype>265</unittype>
		<interfaces>512,513</interfaces>
	</etsiunitinfo>
</device>

2025-05-11 16:07:20.045 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'avmfritz:HAN_FUN_DIMMABLE_BULB:30ac54ca
52:Z001788010D4B55D30B' to inbox.

2025-05-11 16:07:20.282 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'avmfritz:HAN_FUN_HOST:30ac54ca52:Z001788010D4B55D3' to inbox.

The complete log unfortunately contains too much data for me.

Regarding the motion sensors (I don't currently have any leakage sensors): These are already supported and are exposed as type avmfritz:HAN_FUN_CONTACT.

<device identifier="Z84FD27FFFEBDDDB6" id="6037" functionbitmask="524289" fwversion="AppV_67" manufacturer="0x120b" productname="_TZ1800_fcdjzz3s TY0202">
	<present>1</present>
	<txbusy>0</txbusy>
	<name>Motion</name>
	<battery>97</battery>
	<batterylow>0</batterylow>
</device>
<device identifier="Z84FD27FFFEBDDDB601" id="2028" functionbitmask="8208" fwversion="0.0" manufacturer="0x120b" productname="_TZ1800_fcdjzz3s TY0202">
	<present>1</present>
	<txbusy>0</txbusy>
	<name>Motion</name>
	<etsiunitinfo>
		<etsideviceid>6037</etsideviceid>
		<unittype>515</unittype>
		<interfaces>256</interfaces>
	</etsiunitinfo>
	<alert>
		<state>0</state>
		<lastalertchgtimestamp>1746970201</lastalertchgtimestamp>
	</alert>
</device>

[andrewfg]

@cryxy .. many thanks for testing and confirming.

After running “openhab:inbox clear” it no longer appeared. I think this was a caching issue.

Ok. The functionality is therefore confirmed to be good.

Regarding the motion sensors ... These are already supported

Ok. So that confirms that no further action is required.

---

@lsiepel this PR is confirmed to be good for your final approval.

[lsiepel]

Thanks, LGTM