Implement COSensor and FireSensor

[andrasU]

The below deices shall work as real and virtual device

• CODetector
• FireDetector
• RTC

[KKlausl]

As you suggested: I implemented a RTC as a virtual device - but I cannot find corresponding datapoints. the binding adds the RTC correctly - see the picture below - but I see only temperature datapoints, is this correct?

[andrasU]

Your assumption is correct. no configuration of the ODP or IDP values or any channel values are necessary. The binding doing it automatically internal. You can get the values from the free@home through the binding directly to your items.

Additionally I added to the new pre-release lots of Air Quality sensors.

fh-3.4.4-pre3

AQS sensors for Humidity, Room temperatur PM10, PM2.5 VCO, CO, CO2 and NO2 are added

If you have a bit time, could you have a short test with the new version. It would be great. I made a test but more people more environment is better for a final release.

thank you

[KKlausl]

That is great - thank you for your great work. I will test the new release and give you feedback…!!

[andrasU]

That is great - thank you for your great work. I will test the new release and give you feedback…!!

thank you

[KKlausl]

Tested the he virtual devices which are implemented in the current pre-release:

• PM25
• Humidity

Installation creating a thing and item works fine! The first value shown is correct!

Two Problems:

1.) Nevertheless the binding does not update changes and the item "dies". Rebooting OH -> shows the actual value again, but the item will not update.

2.) Only following AirQuality Devices are shown in F@H App: Humidity and CO2. Temperature is only working through RTC. I miss VOC, PM25 and CO. Maybe - as you intended - the integration of

• CODetector
• FireDetector

is a solution. Would you be so kind to Implement COSensor and FireSensor?

[andrasU]

Thank you for the test.

For the problem 1)
If you feed the item with new values in the TTL (Time To Live) of the f@h virtual device the device shall not die. Because the binding will provide new value to the f@hg devide, and the SysAp will see the activity and will keep the device.However this is a good idea to implement a keep alive function in the Thing to provide values automativcally before the TTL time slot is timeouting.
It means if the item is not getting any new value to provide to the Thing and to the f@h device the Thing shall re-send the last valid value again before the TTL timeslot having a timeout.

certainly this keep-alive can be realized on the openHAB side with some scripts, (SendCommand in a loop) but it would be very elegant to make it automatically from the Thing.

I will see how I can realize this config

You have to set an enough TTL slot to have to to be able to provide value updates.The defautl TTL is 180sec. If the Thing is getting in the 180sec a new value which can be provided to the f@h device the device shall not set to unresponsive

For the problem 2)
I did not find also any possibility to display these values on the f@h dashboard, but you can define some actions based on these values.
Maybe the FireDetecor and the CODetecor is helping, but I think these values are able to generate some actions but cannot be displayed on the dashboard.

The temperatur is the same as the VOC, PM25 and other AQ sensors, you are able to define on these sensors an action but you are not able to display it on the dashboard.
At least i did not find any possibility.

[sleugner]

If you want you virtual device to stay alive you can set the TTL Value to -1.
I also like the idea of the script in OH which keeps them alive.
Sometimes I purposely set a low TTL Value if I am only testing something. It would be rather unfortunate if the device would not Die then.
I was also able to manually delete virtual devices with TTL of -1 but I would have to check how I did it.

[sleugner]

Btw updating the TTL is mentioned in the documentation of ABB.
Hier
In the last example „ How to register a virtual device“.
Maybe that helps with the script.

[KKlausl]

If you want you virtual device to stay alive you can set the TTL Value to -1.

That´s true, but all my virtual devices in free@home are set to ttl -1; therefore the idea of the script in OH which keeps them alive could be a solution or also may not be the solution of the problem. hopefully the first is right. :)

[andrasU]

I have currently a problem with the COdetector and FIREDetector, that no documentation is available for these devices, and data points. I do not have any idea which channel / pairing id is meaning what.

I could do some blind implementation

the second problem is the keep-alive function which I planned. this cannot be realised currently because the feature in the SysAP seems to be not working. it is not working at least as documented in the ABB/BJ specification.

to keep the virtual devices alive is the simplest method to define the TTL as -1

Both issues I reported to ABB/BJ, I am waiting to the feedback.

[KKlausl]

thanks again - let´s see if ABB gives feedback....