Superp

Good find. Let us know how it goes. I have used this cable so far, but it takes up too much space in my machines.

Yes, the APIR-2150 works with the Remote Switch Bricklet 2.0, as a type B. It sends "on" when movement is detected (15 repeats), and "off" after a configurable period of non-movement (15 repeats). I use a KlikAanKlikUit branded version, the Trust version I think is identical. ASIN B0146HDCMA Manual A provisional list of tested devices is here.

I would love to have a lightning detector bricklet. But if you would design such a bricklet, please make it such that it can be mounted flat to the inside of a case, with the actual sensor facing out, like the Sound Pressure Level Bricklet.

+1

I just tried with 2x2m: Mac -> USB-C cable -> Master Brick -> 2m 7p cable -> Isolator Bricklet -> 2m 7p cable -> RGB LED Button Bricklet Which works fine, without anything special in brickd.log. YMMV.

I'm not sure it is the ideal solution, but I think it could work, if 1-switch-only is not negotiable. Otherwise, I would maybe use a hard (power) switch, and some user input (button, multitouch surface, ...) and output (LED, display, ...). An RGB button combines both (as a soft switch and LED status indicator): User switches on power (hard switch). System boots, LED turns green when system operational. When user is finished, she pushes the button. LED blinks red. Shutdown happens as you described above. LED turns off. User switches off power (but no drama if she forgets). Should battery run low earlier, LED blinks pink, system shuts down, LED turns off. To resume work, switch on power. Best! P.S. I also considered using something like an Intertechno CMR-1224, but I think that is just convoluted.

Your use of shutdown confuses me. I think you sometimes mean halt (stop running), sometimes power off (cut power supply). When main power drops, first do the necessary housekeeping: stop operations, set system (motors, etc) to a safe state, log event, send alert, write/close files, etc. Then, from your script/daemon/service (this is Ruby): # Shutdown system after 1 minute `sudo shutdown` # Switch off power after 1.5 minutes hat.set_sleep_mode 90, 2**32-1, true, true, true # Finally exit The power_off_duration has a max of 2**32-1, which is 136 years. I think that should do. That final true might as well be false, your choice.

Hello Yvo, Interesting question. I have 0 knowledge of the StromPi. Two ideas: Eliminate the HAT Brick and replace it with one or more Master Bricks connected via USB – you already had this idea. Eliminate the StromPi. Instead, feed > 6v into the HAT Brick's DC input, and connect a power bank to the HAT Brick's USB. The Brick will choose the power source with the highest voltage, so when the Stromhauptversorgung is interrupted, it switches to USB power. Both voltages can be read via the API, so these can be monitored and can trigger an action in your software. Best/Grüße

Fixed in Brickd 2.4.4

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