Bosch AIR

[hbkoenig]

Device

• Product name: Bosch AIR
• Manufacturer: Bosch
• Model identifier: AIR
• Device type :
  • Sensor

Screenshots

most other clusters don't yet provide any or useful/correct info, right now we're mainly focused/interested in the new -02-fdef cluster with the "Air Quality" and overall "room quality" info:

"air.xml" is thie cluster info for deconz (I had to insert it into general.xml, adding it as 2nd file does not work for me -- why??)

[hbkoenig]

hmm, all my drag&drop from firefox showing file://... URLs to insert screenshots did not show up:-( I'll try again...

cut&paste from firefox again shows "Something went really wrong, and we can't process that file. Try again." after "Uloading..."

selecting files in "Try again" file browser window does not work either:-((

please help, how can I provide/upload screenshots etc ???

[hbkoenig]

now trying from my private notebook outside the Bosch firewall -- this seems to work...

air.xml.zip

[hbkoenig]

here you can find a few old marketing infos about the planned product. it's still a prototype, we now try to use 40+ in our building top monitor meeting rooms and offices for better ventilation agains covid19 (and maybe later high noise load in offices and other aspects too):

https://www.bosch-presse.de/pressportal/de/de/bosch-smart-home-air-der-mobile-wohlfuehlsensor-168832.html https://www.hurra-wir-bauen.de/mediathek/ifa-neuheit-bosch-smart-home-air.html https://www.smart-wohnen.de/haus-garten/artikel/der-brandneue-bosch-air-der-mobile-5-in-1-wohlfuehlsensor-fuer-zuhause/

[SwoopX]

Hi and thanks for raising this. Very interesting device, it's presumably a bit more of a challenge to have it fully supported. I'd expect some back and forth regarding testing as we don't have that one at hand, which is not exactly most convenient remotely.

Anyway, it's great that you shared the attributes of that one cluster. Is the other one of any importance as well? It also seems that we have temperature and humidity twice here, are the corresponding values between the endpoints identical (so copied over from cluster 0x0402 and 0x0405 to 0xFDEF)? And for the power configuration cluster, does it use battery percentage (the attributes do not seem to have been read correctly), with which max value (100 or 200)?

[StefanUllmann]

Hi and thanks for raising this. Very interesting device, it's presumably a bit more of a challenge to have it fully supported. I'd expect some back and forth regarding testing as we don't have that one at hand, which is not exactly most convenient remotely.

Anyway, it's great that you shared the attributes of that one cluster. Is the other one of any importance as well? It also seems that we have temperature and humidity twice here, are the corresponding values between the endpoints identical (so copied over from cluster 0x0402 and 0x0405 to 0xFDEF)? And for the power configuration cluster, does it use battery percentage (the attributes do not seem to have been read correctly), with which max value (100 or 200)?

The Idea behind this two end points is to have something which is 100% defined in ZCL. All clusters on EP1 shall behave like defined. EP2 is made as shortcut. All physical measurements are on 0xFDEF and the device config in 0xFEDD. To answer your question, yes, the measured values are copied to both end points. Same is true for basic cluster. Other reason is that in ZCL there is no definition for air quality, we skipped it on EP1 for this reason. Please note that device is under development, EP2 works for us, EP1 is not yet finished.

Missing information to interpret the data on EP2 better:

Attribute 0x4006 is not yet working.

Attribute 0x4009 | Trigger measurement type: 0x30 enum 8 bit Cause of the measurement: Possible values: 00 → timer base 01 → forced by user

Attribute 0x400B | ModeOfOperation type: 0x30 enum 8 bit possible values: 00 → Normal (day mode) operation. 01 → Device turned up side down. (No LED visualisation)

In case of further questions you can also reply directly to me.

[SwoopX]

@StefanUllmann Thanks for the additional input.

Other reason is that in ZCL there is no definition for air quality, we skipped it on EP1 for this reason.

That's indeed part of the challenge here. We recently got 1-2 requests for other VOC sensors and I already discussed with @manup how to best accommodate the required code. Started already on the VOC code, but I currently have some PR dependencies which need to be merged first to gain some freedom back. Meanwhile, I can port the code and work out the device's details there.

Just take note that it would require you to compile and test the code probably a couple of times to verify.

I also assume the attributes are all reportable? If you have any preference there, just let me know, otherwise, I set the intervals to "defaults" min:1, max: 300.

[Mimiix]

@manup Why did we re-open?

[manup]

Version 2.6.0 now contains the first implementation. In my tests joining works very solid, it takes a while until the values are populated though.

Note for already joined sensors the REST-API resources won't be created automatically after the update. The simplest way to get them is to start sensor search and then plug out the battery and but it back in.

The Phoscon App (when connecting via gateway IP) also shows the sensor with some values, there are still some missing which will be added in the next release.

[manup]

@manup Why did we re-open?

It's work in progress

[hbkoenig]

batter

[hbkoenig]

Note for already joined sensors the REST-API resources won't be created automatically after the update. The simplest way to get them is to start sensor search and then plug out the battery and but it back in.

oh, that's possible??? didn't know that:-( I just read this a few minutes too late, I just removed all AIR sensors in deconz in order to restart joining. is there a chance to undo or "ignore" that deleting of all AIR notes and start over ??

[hbkoenig]

oops for closing this issue -- I just wanted to close the comment field with bad/small quoting of selected "batter" text. not my UI (yet;)...

[hbkoenig]

update: after restarting deCONZ with version 2.6.0 all my AIR nodes show up again, surprise! BUT: 2.6.0 now always crashes after some 10 secs -- have to debug...

yesterday evening I did a quick test of the plugin with 2.05.86 (stable) and compiled the plugin myself. that worked for a quick test of REST -- but phoscon of course did not show the sensors...

would "re-joining" by only removing batteries also work th 2.05.86 with new plugin (then without new phoscon), or does this need full 2.6.0 with phoscon?

thanks!

[hbkoenig]

update about crash of 2.06.00: the crash at startup depends on command line options!

will crash now: deconz --dbg-info=7 --dbg-error=7 --dbg-aps=7 --dbg-zcl=7 --dbg-http=7 --dbg-prot=7 works for me: deconz --dbg-info=2 --dbg-error=2 --dbg-aps=2 --dbg-zcl=1 --dbg-zdp=1 --dbg-zcldb=1 --dbg-tlink=1

[Mimiix]

That's to be expected: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-debug-flags

[manup]

would "re-joining" by only removing batteries also work th 2.05.86 with new plugin (then without new phoscon), or does this need full 2.6.0 with phoscon?

Yes that should work for all versions, it's similar to what happens when a device is joined normally. After power-up the device Broadcasts a Device Announce message from there on the pairing machinery starts.

That's to be expected: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-debug-flags

Although the flags are a bit ambitious :) it shouldn't crash the application, looks like a bug.

[hbkoenig]

after fixing some weird problem with ConBee II placements which totally blocked deconz (always error 0xE1), I finally could start joining AIR nodes into our network today.

"re-joining" working nodes by removing batteries worked fine, phoscon found/enabled then and I can rename them. good. adding some more new nodes also seems to be working better, most nodes now join at first try (but not all, TBD).

after some 20 joined nodes, joining didn't seem to work anymore with some new sensors, so I restarted deconz "to be sure".

BUT now, most of the nodes in deconz changed their names after restart:-((( before, all nodes have been named (and labeled;) ZA-nm, now one node is called "Air quality sensor" and 19 nodes now are called "Hymidity abc" with consecutive numbers from 285 to 303. the node names are imporant, they must not change! (and I've never ever seen a "Humdity*" node name before?!).

BUT these new node names show up only in deconz, phoscon still shows all Bosch AIR nodes as ZA-nm what's going on here ???

[manup]

Hmm strange, this should already work. Did you rename the sensors via Phoscon App? This should rename all related sensor resources and store the new names in the database zll.db.

Here is an example of my zll.db viewed in https://sqlitebrowser.org

After reloading these where restored properly for the deCONZ node and in the Phoscon App.

I can only imagine that the names where reset while joining other nodes, I'll check this in some tests.

[stale[bot]]

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[stale[bot]]

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.

[WhistleMaster]

Seems like a promising device ! Is it already available to buy ?