Superp

Michael, you are a goldmine of information. Thank you!

Quote

 It should therefore be possible to read and write them. For me, it would be great if this would be possible

I second that. The Bosch module behaves quite like a black box; it would be helpful if it was a bit more transparent. Even better if you could control what happens inside (re-load calibration). Maybe one of the Tinkerforge guys like @photron can chip in and tell us how likely it is to get this implemented?

CO2 as an alternative measurement sounds like an idea worth investigating. Thank you for explaining the IAQ/CO2 relationship in such detail, very helpful.

BTW, do you not have problems with the LCD Bricklet flooding the Brickd log on your RPi?

Michael,

What a brilliant project you have created!

I had big plans with the Air Quality Bricklet, supplying input for a light art object, but found the readings not reliable enough for a public project (see discussion here).

I know of no way to save/load calibration data. So, I took the Bricklet out of the project, but I am still very interested in using it when I can make the readings "behave".

Best!

Hi Max,

Excuse me for interrupting in the wrong language. I am not sure I totally understand your question, but I'll attempt to help.

You may want to have a look at Totem, a robotics brand.

Among many other things, Totem sells 100x100mm plastic boards which are the missing link between Tinkerforge and Makerbeam.

They have a grid of holes 100% compatible with Tinkerforge, and combine with Makerbeam super easy. I use them all the time to mount Tinkerforge projects to Makerbeam frames.

You can easily cut them to size with a knife, drill or cut holes, or combine several for bigger projects. Because they cost €0.55 each, you can freely experiment.

Hope this helps.

duplicate

Borg, mine has been running FW 2.0.6 for 5 days uninterrupted. It started with accuracy 0. Then 1. Yesterday accuracy was 3. Today it is 0 again, without rebooting.

My point being that IAQ accuracy will vary wildly anyway. Your sample dropping to 0 after reboot may be caused by rebooting (losing calibration), or may be just "normal" behaviour (picking up calibration at some point during previous 12 hours).

That's what I think.

Flashed. Running.

Great! I am pretty busy, but let me know if I can help.

Bump

Hi luxor,

I am looking into some of the same problems, but not working on a disco ball. Modulor I have used and can recommend, too.

For specialist plastics with mirror- or other optical effects, Pyrasied might be of use to you sometime.

I have a suspicion smitae is no longer following. In the meantime, I have some experiences with the Outdoor Weather Bricklet which may be useful to others:

• The TH-6148 Temperature/Humidity Sensor can be mounted outdoors as it is, but I wanted an enclosure for extra protection against rough weather. The TFA Dostmann Schutzhülle (article 98.1114.02) is a perfect fit. Without the mounting bracket, the sensor fits snugly inside the enclosure.
• I also found the TFA Dostmann Thermo-Hygrometer mit Sender 433 MHz für TFA GAIA (article 30.3166) a perfect replacement for the Tinkerforge sensor. It looks identical and has the same dimensions, and also fits in the enclosure. I use a combination of three sensors, one Tinkerforge TH-6148 and two this TFA Dostmann sensor, to transmit data to the same Bricklet, and it works fine.

Still looking for a transparent dome though.

I would really appreciate that.

Since March 2019 the Air Quality Bricklet no longer saves its calibration data, correct?

As it takes 28 days to fully calibrate, and the system here reboots once a month, this yields max 3 days of reliable data per month.

I am willing to work with you to solve this (and invest some time from my side), but if there is no solution in sight I will retire this Bricklet.

Anybody?

The documentation says:

Quote

There is also a blue LED on the Bricklet that is on as long as the Bricklet is in the "motion detected" state.

I might be wrong, but I think there is no such LED (I looked). There are of course the three backlight LEDs ("indicator" lights), but these are software controlled and do not reflect the motion detected status unless you set them manually (as the video here shows).

This might be a leftover from the previous version of the Bricklet:

Quote

The blue LED on the Bricklet is on if the sensor is in the "motion detected" state and is off if the sensor is in the "no motion detected" state.

Could someone clarify, or correct the documentation?

The documentation says:

Quote

Note The currently released firmware (2.0.4) does not save the calibration every 12 hours. We had to disable this because of a bug in the proprietary load/save mechanism that we can't fix. We will release a new firmware that has this enabled again as soon as this bug is fixed.

My Air Quality Bricklet reports firmware_version '2.0.5'.

Does this mean this bug is now fixed?

related commit (Disable automatic calibration load/save for now)

Photron,

Thanks for answering.

I can not think of a way to correct this in software; at unlimited range and 50ms integration time, it is rare but possible to have saturation and a reading of 0 Lux. When this happens and the light is then reduced and stable, the reading appears to decrease over several seconds, e.g. the sensor takes time to recover from overload. Interesting.

One way to solve this might be to have a second sensor with a 10-stop ND filter in front.

According to the documentation, "An illuminance of 0lux indicates that the sensor is saturated and the configuration should be modified".

However, in total darkness, the Bricklet also reports 0 Lux (I checked).

Q: How do I distinguish between A: sensor overloaded by light (too much light), and B: complete darkness (no light)? In both cases I read 0 Lux.

Fixed.

Useful knowledge, filed. I always thought isolators were there just to protect your system; turns out in some circumstances their effect goes beyond that.

Thanks for digging this deep, and finding a solution.

Hello,

I have an NFC Bricklet that is factory new: it has only been accessed through Brickv to do some test scans.

When I call #get_detection_led_config it returns 4. That value is not in the documentation. What does '4' mean?

Photron,

Good to hear there are plans for brickd health reporting in the API. I hope this gets implemented soon. In my priorities, this goes to the top.

Whether a system will fall over or not, I am not going to bicker with you over this. I will say, however, that I have seen brickd producing several hundred messages per second and yet respond normally to calls, and that is a showstopper.

Best!

Hello Photron,

Thanks for taking the time.

This is a problem already reproduced and confirmed by your colleague. For your benefit, I have shutdown the system this morning, disconnected all devices, connected the LCD, and booted. Start Brickv, select LCD, and the log starts to flood. This should be fairly easy to reproduce by you.

API calls are answered okay, except the system will ultimately become unstable and will no longer boot because it will run out of disk space, I suppose.

The real problem, and for me this is a showstopper, is that client-side (through the API), there is no way to detect problems like this or basically find out if brickd is okay. Brickd will happily answer API calls, while brickd.log is flooded with error messages. This can happen with other scenarios (not the LCD bricklet), too.

Here is an idea: A basic API call to report the current log size (Tinkerforge::IPConnection#brickd_log_size), or error count, or some other "health indicator", would be a great first step towards making things more robust.

Throttling log messages would be helpful, too.

Cheers.

For the record:

This bug was fixed with commit c10086f8ca1223715261fa3c4362f6a5e578305a ruby: Fix bool array unpacking.

Hello Erik,

The above version appears to fix this bug. The debug code I supplied above reports a correct answer.

Cheers,

Hello,

Maybe I'm wrong, but I have a suspicion BrickletSegmentDisplay4x7V2#get_segments does not return correct values.

I think the Bricklet responds with correct data, but the data is mangled when unpacked.

To be precise, when data is unpacked for the first segment (8 values), too much data is slurped so nothing remains for the other 27 values.

Here is a quick & dirty debug helper:

module Tinkerforge
  class BrickletSegmentDisplay4x7V2

    def debug_get_segments
      puts '                 |.......|.......|.......|.......|.|'
      puts 'get_segments   : ' + get_segments.flatten.map { |b| b ? '1' : '0' }.join
      puts 'actual response: ' + (send_request FUNCTION_GET_SEGMENTS, [], '', 14, '?35' ).map { |b| b ? '1' : '0' }.join
      puts ''
    end

  end
end

Okay, thanks. Good to know. I'll keep the LCD disconnected for the moment, until I hear from you.

I might try the brickd downgrade later.

Let me know if I can help with testing etc.