Jump to content

Superp

Members
  • Gesamte Inhalte

    124
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    6

Posts erstellt von Superp

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

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

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

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

    1. When V3 will become available, and
    2. 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.

×
×
  • Neu erstellen...