Superp

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?

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

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> <bricklet_stack.c:478> Message checksum error (port: G, count: 5724) Question #1: Can you point me to a document somewhere outlining what to do in a case like this? How do I diagnose and solve this problem? Both the Brick and the Bricklet do not seem to report these errors through the API (this is Ruby): > hat.get_identity => ["S2c", "0", "i", [1, 0, 0], [2, 0, 2], 111] > hat.get_spitfp_error_count => [0, 0, 0, 0] > lcd.get_identity => ["R3S", "S2c", "g", [1, 0, 0], [2, 0, 9], 298] > lcd.get_spitfp_error_count => [0, 0, 0, 0] Question #2: Using the API, how can I check for problems like the above (excessive checksum errors) ?

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.

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.

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 three. This is my third week of using TF and I hope to make it part of a fairly big project.

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 device_display_name. How do I map numeric device_identifier to class and file? One way would be to load all 139 device classes, and than loop through all Tinkerforge::Device descendants until I find the one with the matching DEVICE_IDENTIFIER constant. That sounds like a really bad idea. Has anyone figured this out yet?