Jump to content

Superp

Members
  • Content Count

    23
  • Joined

  • Last visited

Everything posted by Superp

  1. 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 senso
  2. 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.
  3. The documentation says: 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: Could someone clarify, or correct the documentation?
  4. The documentation says: 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)
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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!
  10. 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), ther
  11. For the record: This bug was fixed with commit c10086f8ca1223715261fa3c4362f6a5e578305a ruby: Fix bool array unpacking.
  12. Hello Erik, The above version appears to fix this bug. The debug code I supplied above reports a correct answer. Cheers,
  13. 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_
  14. 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.
  15. This problem has not been solved yet. With LCD 128x64 Bricklet: 4-5 "Message checksum errors" per second, logfile flooded. Without LCD 128x64 Bricklet: no errors. Do you need more time to investigate, or do you need more info from me?
  16. Yes, brickd is 2.4.3: brickd --version 2.4.3 This is on a Pi 3B+. The problem seems to be specifically with the LCD. Brickv (with the LCD tab active) triggers several errors per second. It may be a thing with callbacks? Anything else I can do to solve the LCD problem? (The problem with monitoring brickd health remotely I am parking; I might get back to that later.)
  17. Hello, I have a problem with a brand new LCD 128x64 Bricklet connected to a HAT Brick with a brand new cable. The Bricklet is responding normally to API calls. brickd.log shows thousands of errors like this: 2020-12-18 08:52:06.937629 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5721) 2020-12-18 08:52:24.206204 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5722) 2020-12-18 08:52:41.476851 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5723) 2020-12-18 08:52:58.746923 <E> <b
  18. Very nice project! I like how you installed the electronics behind a transparent panel. I am looking for something similar: a weatherproof case or housing that does not block too much light/UV. Can you share some more information about the dome you are using and the way you installed it? A picture maybe? Do you compensate your measurements somehow for light blocked by the dome? Thanks for any info you can share.
  19. So, I think I found a working solution, which I'll share here in case anyone else runs into the same limitation. Tinkerforge.device_info 2103 => [2103, "LED Strip Bricklet 2.0", ["Tinkerforge::BrickletLEDStripV2", "bricklet_led_strip_v2"]] and my_devices = Tinkerforge.connect.discover Source here.
  20. Hi Photron, Thanks for responding. I am basically just a lazy programmer who likes magic. What I have done so far is write a little bit of Ruby that 1) takes stock of Device descendants. 2) requires one of TF's source-files. 3) takes stock again and compares to (1) to identify any newly defined class. 4) gets DEVICE_IDENTIFIER and DEVICE_DISPLAY_NAME from the newly defined class. 5) Repeats for all source-files. This generates a device_info.txt which maps device_identifier, device class, source-file, and device_display_name. You can use any of these four to look up the other thr
  21. Hello, I have a question about discovery of devices with Ruby. Enumeration supplies the numeric device_identifier for each device, for instance 2103 for a 'LED Strip Bricklet 2.0'. See documentation. Next steps would be to load the file defining the matching class, and to initialize an instance of that class: require 'tinkerforge/bricklet_led_strip_v2' Tinkerforge::BrickletLEDStripV2.new ... In other words, I need the name of the matching class for a '2103 device' and the file which defines that class. Tinkerforge::DEVICE_DISPLAY_NAMES only maps device_identifier to
×
×
  • Create New...