Do you see EVENT messages in the log? According to the json you sent me, the Characteristics should support eventing. In which case the accessory would send an EVENT whenever the value changes.
However maybe your device does not implement its promise to send EVENTs, or maybe it applies some rate limiting internally.
And keep in mind that CO2 sensors (depending on the technology) may have a very long time constant e.g. the (de)absorbtion of a gas into a molecular substrate..
I see EVENT messages in the log but only on manual requests. Means, if i put the finger on top of the sensor, the sensor responses by a LED bar and shows the color of the actual CO2 range acc. to the iOS app. In parallel the EVENT messages appear and data is updated.
I have used this playing arround with CO2 up and down. Then the EVENT log entries appeared. I also recognized that the manual request canât be repeated quickly. It needs a timeout as well until it reacts a 2nd time.
The technology limitation you mentioned makes sense and determines the possible data update. This sounds plausible.
Probably your device has a slow background update cycle combined with a fast refresh when manually triggered.
In any case, I think that in the OH you get what you get from the device. So there is nothing to be done on my side.
Small update: while configuring a work-around for this issue by using the State Filter Profile, I found a bug in the UoM implementation. This got in the way of using this profile. There is already a fix, which will be included in 5.1.2:
With that out of the way, an Item configuration could now look lilke this:
Number:Dimensionless Netatmo_FamilyRoom_CO2 "CO2 [%.0f %unit%]" <carbondioxide> (Netatmo_FamilyRoom, Max_CO2) ["Measurement", "CO2"] {
channel="netatmo:weather-station:home:indoor:airquality#co2",
channel="homekit:bridged-accessory:netatmo1:family_room:sensor-carbon-dioxide#carbon-dioxide-level-13"
[ profile="basic-profiles:state-filter", conditions="> 0 ppm" ],
unit="ppm",
expire="60m,state=400 ppm"
}
I recently noticed that my modules needed recalibration, and a few of them went below 400 ppm, I think down to 370 ppm or something. Therefore I plan to tweak this configuration a bit, so that the expiration state will be 300 ppm to be sure itâs below any real measurements. A persistence filter could then be used to avoid actually persisting that.
For reference, anything below 400 ppm even locally is highly unlikely by now: CO2 Ice Core Data
@dk8pn - maybe youâd want to slightly rename this thread, so it implies we are discussing HomeKit integration? 
Changed the title of the thread. Okay, or any other proposal?
@AndrewFG: Have once per hour the following log entry.
2026-01-12 08:53:53.253 [WARN ] [.handler.HomekitBaseAccessoryHandler] - homekit:accessory:0e9540bb9768 host name 'Healthy Home Coach (2)._hap._tcp.local.:5001' does not match expected pattern; using anyway..
See it for one of my three sensors only, but all 3 have the same settings (if i made no mistake 
). Do you have a hint for me how i can get rid of this warning.
It means that the host name is invalid. Probably the spaces, and/or the brackets. In your case you are lucky that it seems to work anyway.
What is the host name on the other two accessories? And how did you set the host name on this one?
Normally the host name comes from the mDNS auto discovery. Can you use a third party mDNS app to see the original host name of the devices as they report themselves via mDNS?
Initially the host names as of the log entry have been set automatically as above. Then i misunderstood one of your comments and changed to IP:port for better identification in the log. Later i reverted my change to the original names as above.
To avoid a mistake i doublechecked them now and copied the manually reverted adresses again into this post:
Healthy Home Coach._hap._tcp.local.:5001 (192.168.1.163:5001)
Healthy Home Coach (2)._hap._tcp.local.:5001 (192.168.1.165:5001)
Healthy Home Coach (3)._hap._tcp.local.:5001 (192.168.1.164:5001)
The 3rd sensor doesnât occur in the log. Will try a 3rd party mDNS app.
Two things:
Okay. The \032 is in the log but not in the MainUI screen of the thing. I just used Windows11 Powershell and retrieved the following (same sensor order as above, Wohnzimmer .163, Arbeitszimmer .165, Schlafzimmer .164).
PS C:\Users\willi> Resolve-DnsName 192.168.1.163
Name Type TTL Section NameHost
---- ---- --- ------- --------
163.1.168.192.in-addr.arpa PTR 9 Answer co2wohnzimmer.fritz.box
163.1.168.192.in-addr.arpa PTR 9 Answer Healthy Home Coach-3.fritz.box
163.1.168.192.in-addr.arpa NS 9 Authority fritz.box
PS C:\Users\willi> Resolve-DnsName 192.168.1.165
Name Type TTL Section NameHost
---- ---- --- ------- --------
165.1.168.192.in-addr.arpa PTR 9 Answer co2arbeitszimmer.fritz.box
165.1.168.192.in-addr.arpa PTR 9 Answer Healthy Home Coach-2.fritz.box
165.1.168.192.in-addr.arpa NS 9 Authority fritz.box
PS C:\Users\willi> Resolve-DnsName 192.168.1.164
Name Type TTL Section NameHost
---- ---- --- ------- --------
164.1.168.192.in-addr.arpa PTR 9 Answer Healthy Home Coach.fritz.box
164.1.168.192.in-addr.arpa NS 9 Authority fritz.box
Can we trust Windows Powershell?
A mDNS utility on my iPHone brings different results (same order as above):
For 192.168.1.163:5001: Healthy Home Coach_hap._tcp.
For 192.168.1.165:5001: Healthy Home Coach (2)_hap._tcp.
For 192.168.1.164:5001: Healthy Home Coach (3)_hap._tcp.
Another mDNS utility on my iPhone brings these results (same order as above):
For 192.168.1.163:5001: Healthy\032Home\032Coach-3.local:5001
For 192.168.1.165:5001: Healthy\032Home\032Coach-2.local:5001
For 192.168.1.164:5001: Healthy\032Home\032Coach.local:5001
Have only limited trust on these results?
Indeed.
Many accessories expect to receive the exact same Host: header string in the bindingâs HTTP requests as they themselves have previously published in their own mDNS advertisement. But it seems that OH and other mDNS apps are applying extra sequence numbers (in various formats) to disambiguate duplicates. These extra sequence numbers risk to make duplicate devices not work. But you are lucky that your devices apparently do not enforce that rule. However I need to dig into this further to figure out a universal solution.
Updated now to OH 5.2.0-SNAPSHOT #5106. Now the Host header adress looks like this:
Healthy\032Home\032Coach-2.local:5001
Did you make this happen?
Yes. Do you confirm that it is still working?
Yes, it is still working. See now warnings like below. From each IP approx. every 2 hours.
2026-01-17 09:32:36.510 [WARN ] [mekit.internal.transport.IpTransport] - 192.168.1.164:5001 received EVENT while waiting for HTTP response
2026-01-17 09:32:51.323 [WARN ] [mekit.internal.transport.IpTransport] - 192.168.1.164:5001 received HTTP response but no thread was waiting
2026-01-17 09:37:47.596 [WARN ] [mekit.internal.transport.IpTransport] - 192.168.1.165:5001 received EVENT while waiting for HTTP response
2026-01-17 09:38:02.421 [WARN ] [mekit.internal.transport.IpTransport] - 192.168.1.165:5001 received HTTP response but no thread was waiting
@AndrewFG, one more observation: within the configuration screen, there is a small blue â1â which indicates âNon-default advanced parameterâ. Either didnât recognize this earlier or it is new?
Many thanks, understand the purpose of this âhintâ now.
Probably the behavior was alway there. But the warning is new. The issue is that the transport processes incoming messages from the device, and if there was no GET request in process it would be forwarded as an EVENT but otherwise forwarded as a response to the GET. And the log message indicates that an EVENT came in overlapped during a GET so the transport doesnt know what to do. I was hoping that this would be so rare that we could ignore it. But every two hours indicates that I cannot.
EDIT the 15 second interval between the pairs of messages, means that the EVENT caused the GET reaponse to be lost. Either it was sent and missed, or it was not even sent. And then the GET timed out. => So I need to either recover the response, or resend the GET, or at least simulate a dummy response.
