Hello, I just received and commissioned two new AirLab AL-CO2-TVOC-W units, connected them via RS-485 and used the T3000 S/W to review operation and all seemed well. I then do as I always do with new IoT devices, and check for a firmware update.
The software doesn’t appear to verify if the currently installed firmware is up to date, instead it’s only choice is to download and update, which I did. After updating, the Occupancy Sensor no longer updates on either unit, either through the T3000 software, or via BACnet integration.
The version in my Firmware folder appears to match the one available online in the ’ /ftp/firmware/AirQuality/’ folder (11_5).
Is there a later version in the currently-shipping sensors than what is available online? What else could cause these two sensor elements to both stop updating?
The first thing that happens when you select ‘Download Firmware and Update” is T3000 will check what version of firmware is on the device and compare that with the latest version from the firmware update repo site. If there is a new version it will be downloaded to your hard disk and a message will pop up to show you the changes that have been made lately. I notice for the Airlab that we haven’t loaded the revision notes yet so we’ll get that done now. Once the firmware is downloaded it will be automatically loaded to the device, you can monitor the progress in the update dialog.
If you have more than one device to update, T3000 will take the firmware already cached on your PC so the update will move along more quickly.
Regarding the occupancy sensor, the default values may be out of line. Here I have adjusted the trigger value to 500 to see if I can get some action out of it, this is the adc value from the occupancy sensor. I just spoke with the developers here and see we have some work to do on making this occupancy sensor work more like an occupancy sensor and less like a temperature sensor. We’ll get this straightened out asap. Thank you for bringing this up.
I noticed when I first connected to the units and before updating the firmware, the ‘Occupied/Unoccupied’ text indicator boxes were updating. After the updates, they never change. Also, after the updates, AI17 is not updating via BACnet.
I found that there are more modbus registers available in the Modbus Register list document than there are shown if the sensor register list is chosen from the ‘Tools → Register Viewer’ application. I noticed that the MODBUS_PIR_SELECT_ENABLE’ value was set to 0, so I updated that and if I set the threshold value above the real ‘unoccupied’ value, I was able to get the Occ_Alarm register to trigger (the PIR_Status still doesn’t update)
please follow Maurice 's steps to update firmware to 11.8 , and confirm the following two registers value ,
- MODBUS_PIR_SELECT_ENABLE REG736=0,
- MODBUS_OCC_TRIGGER REG633<=50 ,
Firmware on one unit has been updated to 11.8. The register numbers on your example do not match the values shown in my Register Viewer.
The Occupied/Unoccupied values on the sensor home screen do not change with the occupancy state, but the OCC Alarm value does toggle when the value exceeds the trigger level. Also, the value is not listed in the table under AI17, like it is listed in the Register list and as it is discovered in a BACnet discovery.
Root data source questions: why does the Register Viewer table not include all of the registers listed in the online Register document? There are useful parameters in that document (that appear to be linked to real values, like PIR Sensitivity)?
Why are the configuration values (timer & trigger levels) not Writable BACnet objects? In the commercial use market, the BACnet functionality should be equal to the Modbus functionality and all of the values and conditions visible in one protocol should be visible in both so that the sensor could be utilized in whatever building environment that we have available to us.
Of the two AL-CO2-TVOC-W units that I bought for evaluation purposes, one is reporting that there is no WiFi module recognized:
I have power-cycled it many times, but most of the time it says ‘No WiFi Module’ - sometimes it says ‘Abnormal WiFi Module’ and occasionally ‘WiFi No Connect’. It NEVER reports a MAC address, even when the other values populate correctly. What’s the next step for this unit?
The registers list in resgister viewer table is a little old , the latest version as follow link address ,
https://downloads.bravocontrols.com/file/air-particle-quality-sensor/technical_doc/latest ,
The description of the PIR sensor registers is clear as shown, and your trigger value is set to 200, it is recommended that you change to 30 to 50.
BACnet AI17 is PIR state, 1 is occupied, about 1 second duration If the polling period is greater than one second, maybe the status of the PIR will not be correctly display.
Modbus poll (REG736) and Yabe (AI17) can correctly display PIR status when their polling time set from 1 to 2 seconds .
