Jump to content

Superp

Members
  • Gesamte Inhalte

    133
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    6

Posts erstellt von Superp

  1. 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.

  2. 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):

    1. User switches on power (hard switch).
    2. System boots, LED turns green when system operational.
    3. When user is finished, she pushes the button. LED blinks red. Shutdown happens as you described above. LED turns off.
    4. User switches off power (but no drama if she forgets).
    5. Should battery run low earlier, LED blinks pink, system shuts down, LED turns off.
    6. 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.

     

  3. 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.

  4. Hello Yvo,

    Interesting question. I have 0 knowledge of the StromPi. Two ideas:

    1. Eliminate the HAT Brick and replace it with one or more Master Bricks connected via USB – you already had this idea.
    2. 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

  5. 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

  6. 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

  7. 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.

    • Like 1
  8. 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?

    • Like 1
  9. 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.

×
×
  • Neu erstellen...