Superp

Wow, sounds cool. Thanks for the exposé. I would be careful not to introduce another variable factor through difference in density/composition/thickness/texture/orientation of the diffusers, but you no doubt have realised that already. Best!

You're welcome. Now everybody is wondering what kind of project involves 3x3 light sensors.

Some ideas: Kenko KFM-200 Flat Diffuser for KFM-1100 Kenko Sphere Diffuser KFM-300 for KFM-1100 flash diffuser dome ping pong ball diffuser Pyrasied optical plastics Polyacetal

Thanks, @batti, for writing your annual review and outlook. With only 1 blogpost so far this year, and much of the forum activity now happening around Warp, things have sometimes been quiet, especially for non-German customers. Eerily quiet, at times. So, it's good to hear Tinkerforge is alive and well, hiring new people and moving to bigger premises. Congratulations on the success of Warp! Your account of the problems you encounter in today's market is informative and much appreciated. Thanks for producing a line of amazing products! I look forward to interesting conversations in 2023, and wish you and the Tinkerforge team the very best. Also: Review 2021 - Outlook 2022

Update 22-Dec-2022: Implemented in Brickv 2.4.23, integrated into Tinderfridge 0.13.0. That would be great, @photron. Note to self: It is not necessary to specify the path to Brickv. On my Mac this works too: open -n -a Brickv This is shorter, and works when Brickv is installed in a different directory (I have it in ~/Applications). Brickv may be spelled all-lowercase brickv, too. Thinking about integrating this with Tinderfridge. Also: Brickv commit

Thanks for this, very helpful. Would be even better if Brickv supported arguments, to connect without further interaction: open -n /Applications/Brickv.app/ --args pi3.local

What is the battery status it reports, when it works?

You're welcome!

Yes, the + indicates where you connect the DC+. Left-side, closest to the USB-C port.

Hi guys, Sorry for entering the discussion in the wrong language. I have used mapping for sensor id's since about six months, and it makes life much easier. Your discussion prompted me to publish the (Ruby) code. Maybe this gives you an idea of how (not) to do this. Here is an example of the result: # retrieve data for all sensors my_weather_bricklet.sensors => {163 => [19.0, 54, 25], 202 => [11.1, 70, 45], 233 => [7.5, 47, 26]} # define sensor mapping for 2 sensors my_weather_bricklet.config['sensormap'] = { 163 => 'livingroom', 202 => 150 } => {163 => "livingroom", 202 => 150} # retrieve data for all sensors, again my_weather_bricklet.sensors => {"livingroom" => [19.0, 54, 26], 150 => [11.1, 70, 46], 233 => [7.5, 47, 27]} For weather stations, this would obviously work similarly. Maybe this helps a bit.

Pi 3 model B+ available at Kiwi. Not listed on rpilocator. Sold out!

How about the Industrial Dual Relay Bricklet ?

I think you're right – once a Bricklet has booted 2.0.3, ASC is on forever – but I am not sure. Would be nice if e.g. @borg could confirm.

I don't know. Did you read the thread I linked to above? Firmware < 2.0.3 did not touch ASC, it was assumed to be activated during manufacturing. But, apparently, at least some Bricklets were shipped with ASC not activated. So, I would say, a Bricklet that has never run 2.0.3 has ASC in an unknown state. 2.0.3. activates ASC. 2.0.2. and older do not touch ASC. So the question is: does the Bricklet retain the state of ASC between restarts?

Hi Gabrojas, It is not possible to switch ASC on/off via API with the current firmware. That other thread ultimately led to firmware 2.0.3, which forces ASC on at startup. Before that, at least some CO2 Bricklets erroneously shipped with ASC switched off. I would welcome the option to control ASC manually, but if you know how to build firmware, it might be feasible to implement yourself. This is the diff for the above FW change. Hope this helps.

Cross reference: ASC beim CO2 Bricklet deaktivieren

Cross reference: CO2 Bricklet 2.0 accuracy

Have you tried using a different cable?

I already ordered one earlier today. All looks fine, size is now 40x40mm. The documentation seems a bit inconsistent re onboard antenna?

Dear Tinkerforge, I am aware a GPS Bricklet 3.0 is in the pipeline. I am assuming V3 will support Galileo, and V2 will not be upgraded to support Galileo. Can you share with us: When V3 will become available, and How it will be different from V2? I have a little project incorporating a GPS, and at some point want to finalise the design and order the parts (using a GPS V2 for prototyping at the moment). Thanks for any info.

Hi Rik, Regardless of the programming language, my advice would be to use a callback. But the current documentation does not mention callbacks for this Bricklet and Java. The docs mention callbacks for Java and other devices (example: Accelerometer Bricklet 2.0), and for the NFC Bricklet and another language like Ruby. Maybe something is wrong with the documentation?

Thanks, will order some.

Dear Tinkerforge, The Outdoor Weather Bricklet has been out of stock for a while. For me, this is a vital Bricklet. Can you give us an estimate date for when it will be in stock again, or is it being phased out?

...and they are sold out again at Kiwi.

For anybody else who has HAT Brick based projects stalled because it is impossible to buy RPi's: Kiwi Electronics has Raspberry Pi 3 model A+ in stock since yesterday.