yvo

Hi List Last summer I was asking about the set_sleep_mode of the RaspberryPi using the BrickHAT. You will find the original post here. And the solution proposed by matzeTF was perfect. The background was, to control the shutdown of the RPi in a controlled way in combination with an Industrial-Dual-Relay Bricklets and a second power-supply of HAT and RPi using the 5V USB-connection. This combination allows a controlled shutdown of the entire system and a final cut of any power-supply of the system. This works perfectly so far with RPi-4. In the meantime, I switched to RPi-5 for a new edition of the entire setup. And with this switch, I am confronted with the new following effect: After calling the set_sleep_mode() -function, the system starts to shutdown as defined. But, at the end, the Industrial-Dual-Relay is not set back to default (no connection between A and SW). As a result, the system gets blocked in the following state: The system of the RPi is down. The Industrial-Dual-Relay still provides connection between A and SW. The HAT and RPi gets still power. The only solution to solve the problem is, to manually disconnecting the USB-power-supply from the HAT. After the disconnecting, everything goes and stays as it should (no connection at relay between and SW. Unfortunately, this behavior is not observed systematically. It occurs sometimes. While writing this post, I started the reflection, if the power_off_delay with 5.0 seconds is to optimistic and if the problem could be solved using a longer time-period for the power_off_delay. Do you have any ideas or suggestions? Looking forward to any hints. Cheers. Yvo

Hi MatzeTF Fantastic. Thank you very much for the quick and positiv replay. Then I will implement it in this way. Cheers. Yvo

Dear List I am running a measurement-station using an Industrial-Counter-Bricklet to monitor the frequency given by an encoder: One application is accessing the Industrial-Counter-Bricklet every 5 seconds reading the current frequency on channel 0 and provides the information to a Prometheus-monitoring system. That works perfectly A second application could take usage of the measurements of the Industrial-Counter-Bricklet to monitor its own functionality. For this, it has to read the frequency on channel 0 of the Industrial-Counter-Bricklet as well. This in a similar rate such as every 5 seconds. Question: Is it safe and reliable to access an Industrial-Counter-Bricklet (or any other bricklet) reading the values from two individual applications using the same host and port? Or is it recommended to use a second bricklet. To keep the two applications fully independently, I try to avoid an exchange of the measurements between the two applications through a kind of communication-protocol. Looking forward to any suggestions and hints. Cheers, Yvo

Dear MatzeTF Thank you very much for the quick replay and the hint about the AA-battery. Works for me. Cheers

Dear list I have many installations running using the Real-Time-Clock bricklet. All the installations are running remote and are difficult to access (tunnel-construction sites). The installations are running for about 24 months. During the long duration of the installation, some batteries of the Real-Time-Clock bricklets are getting to low-voltage and the support of the RTC is not given anymore,. Question: Is there a way or method, to monitor the battery-voltage of the RTC-bricklets? Such kind of monitoring could allow to plan the exchange of the backup-battery of the RTC-bricklet. Looking forward to any ideas and hints. Cheers, Yvo

Dear list Some bricklets are used by services written as Python-scripts started automatically at the startup of the RaspberryPis were the applications are running. One of those bricklets is an IndustrialDualRelay. At the start of the service / of the script, I am getting sometimes the following exception: Exception during usage of DualRelay: Did not receive response for function 255 in time (-1) Question: Can it be, that the service starts to early and the connection to the bricklet cannot be established? And do you have any suggestions? Thank you advance for any ideas and hints. Cheers. Yvo

Dear MatzeTF Ahh, sometime the solution is to easy to be found. Thank you very much for the hint. Works perfectly. Cheers and a nice weekend. Yvo

Dear list In the meantime, I implemented the proposed approach of Backdraft007 using the connection-position of the bricklet at the HAT. That works perfectly. Usually I am using wrapper-classes for the individual types of bricklets. In this case, I am using multiple IndustrialDualRelais with different jobs each. The rugged-approach is simply extended by a variable and a if-clause to decided, if the bricklet will be connected or not: def _callbackEnumerate(self, uid, connectedUid, position, hardwareVersion, firmwareVersion, deviceIdentifier, enumerationType): if enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED or \ enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE: if deviceIdentifier == BrickletIndustrialDualRelay.DEVICE_IDENTIFIER: if position.upper() == PermanentPower.POSITION_HAT.upper(): self._dualRelais = BrickletIndustrialDualRelay(uid, self._ipcon) The constant value POSITION_HAT defines the position of the connection at the HAT (A ... H). For my applications, this approach solves the requirements, Cheers. Yvo

Dear list For a measurement-device, I had to implement a delayed shutdown of the entire device. The device is a RPi in combination with a HAT. The delayed shutdown and power-cut is realized using a manual switch and a IndustrialDualRelais. You will find a more detailed description in the following thread (last entry): Combined power-supply of HAT and RPi Reason for the delay is, to provide more time to the RPi to write all data to the disk. The approach described in the link above works perfectly. But ... I am cutting the power-supply of the RPi the hard-way without running a proper shutdown of the RPi. But if I am calling a correct shutdown of the RPi by os.system("sudo shutdown now") the HAT will not react anymore and the used HAT-funktion hat.set_sleep_mode(0, 2**32-1, True, True, False) is not working/called anymore. Question: Any ideas to combine a shutdown of the RPi, the hat.set_sleep_mode and the following cut of the entire power-supply? Looking forward to any ideas and hints. Cheers. Yvo

Dear all Time is running. But I am currently implementing the proposed solution: Main power-supply of HAT and RPi through the HAT 28V power-connection using 20V to 25V battery-power. Additional power-supply of HAT and RPi through the HAT USB-C 5V power-connection. The main power-supply is connected to a hardware-switch. And the USB-C supply is connected through a IndustrialDualRelais. At startup using the main-switch, a service defined at the RPi starts a PowerWatcher Python-application. The application immediately turns the 5V power-supply on. During the runtime of the RPi, the PowerWatcher checks every second the power-input of the main power-supply of the HAT. If the current drops below the power provided by the battery (main-switch turn off by human), the PowerWatcher starts the shutdown-procedure. The shutdown-procedure delays the cut of the 5V power-supply by a configured time. If the main-switch is turned on again by human, the shutdown-procedure stops. As soon as the configured delay-time is reached, the PowerWatcher turns off the entire setup using hat.set_sleep_mode(0, 2**32-1, True, True, False) With turning off the bricklets as well, the 5V power-supply gets cut as well and the entire unit is without power-supply. So far, it works. A still open question is, how to use the function set_sleep_mode-function and a proper shutdown-command in combination. But I will ask this in a separat thread. Cheers, Yvo

Dear photron Great, I just updated brickd using the update-tool of the Raspberry and it works. Thank you very much for all your work. Cheers, Yvo

Dear photron Great, I just updated brickd using the update-tool of the Raspberry and it works. Thank you very much for all your work. Cheers, Yvo

Hi JonD Have you been successful in the meantime to install and using brickv? I have probably the same error. Cheers, Yvo

Dear list I followed the installation-instruction as given on the website for brickd and brickv. After the installation of both, I tried to connect to the attached HAT (version 1.9) using brickv. The brickv started without any problems. But brickv wasn't able to connect with localhost: An connection error occurred. Please check host, check port and ensure that Brick Daemon is running: [Errno 111] Connection refused Trying to start brickd manually, I got the following information: 2024-07-01 16:50:12.151642 <I> <main_linux.c:369> Brick Daemon 2.4.5 started (pid: 2989, daemonized: 0) 2024-07-01 16:50:12.151654 <I> <main_linux.c:375> Running on Linux system (sysname: Linux, release: 6.6.31+rpt-rpi-v8, version: #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29), machine: aarch64) libusb: warning [libusb_init] installing new context as implicit default 2024-07-01 16:50:12.155327 <I> <bricklet.c:304> Found supported HAT product_id 0x084e in device tree, using default HAT Brick config 2024-07-01 16:50:12.155332 <I> <bricklet.c:345> Found Bricklet port A (spidev: /dev/spidev0.0, driver: gpio, name: gpio422, num: 422) 2024-07-01 16:50:12.155355 <I> <bricklet_stack_linux.c:87> Using spidev backend for Bricklets (unsupported suffix 5 after 'Raspberry Pi' in /proc/device-tree/model) 2024-07-01 16:50:12.155383 <E> <gpio_sysfs.c:77> Could not write to '/sys/class/gpio/export' to export GPIO 422: EINVAL (22) 2024-07-01 16:50:12.155386 <E> <bricklet_stack_linux_spidev.c:78> Could not export gpio422: EINVAL (22) 2024-07-01 16:50:12.155505 <I> <main_linux.c:563> Brick Daemon 2.4.5 stopped Question: Do I have to install a brickd-version for 64bit manually? And if yes, which version would that be? Or do you have any other ideas and recommendations? Browsing the forum, I found several issues like the current one: 12334-error-installing-brickd But somehow, I didn't understand the solution. Looking forward to any suggestions. Cheers, Yvo

Hallo MatzeTF Super, vielen Dank für Deine umfassende Rückmeldung. Alles klar, das passt so perfekt. Mit den besten Grüssen, Yvo

Hallo TinkerUnity Ich setzte Real-Time Clock Bricklet 2.0 um den Zeitstempel von Messungen zu garantieren. Die Bricklets hängen jeweils an einem HAT-Brick und dieses an einem RPi4. Die Bricklets gingen etwa im vergangenen August 2023 in Betrieb. Seit der vergangenen Woche Januar 2024 scheint ein Bricklet die Zeit regelmässig zu vergessen, respektive setzt sich auf 01-01.2000 zurück. Das heisst, die Bricklets sind nun etwa 6 Monate im Betrieb. Ich kann aber nicht sagen, zu wie viel Zeit der RPi vom Strom getrennt ist. Als Stützbatterie nutze ich die von Tinkerforge mitgelieferten Batterien. Fragen: Gibt es eine Möglichkeit, aus der Ferne die Spannung der Batterien zu prüfen? Gibt es Erfahrungswerte über die Lebenserwartung der Stützbatterien? Gibt es Alternativen zu den Stützbatterien? Zum Beispiel über eine sehr schwache externe Stromversorgung. Freue mich auf jede Idee oder Hinweis. Mit den besten Grüssen, Yvo

I will do. The cable is not on stock right now. But should be delivered by mid-December. Let's see.

Backdraft007 In the meantime, I found a hopefully suitable cable: https://www.audiophonics.fr/en/power-supply-accessories/male-90-angled-usb-c-to-bare-wires-power-cable-22awg-25cm-p-13575.html I will see, how it works. Cheers, Yvo

Hi Backdraft007 Thank you very much for the link. Looks promising and worth a trial. A downside will be, that I will introduce an open connection more. Currently, I prefer to cut cables to avoid an addition, for humidity and vibrations, delicate connection. Cheers, Yvo

Dear batti Thank you very much for the advice and pointing out the precise location. I had a look at the HAT itself, puhh, this is all pretty small. I guess, this will exceed my skills of soldering 😟 I re-checked the available space between the USB-socket and the case were the RPI and the HAT are located: There are 15mm available. Using an USB-cable with a 90-degrees rotated plug, it should fit. See attached images. Probably, buying such cables, cutting and just using the two power-wires will be easier than soldering an additional cable onto the board of the HAT. Hope you agree. Cheers, Yvo

Hi Backdraft007 Perfect. Thank you very much. In this case, I will go with the positions of the bricklets. That sounds the most promising. Cheers, Yvo

Dear List I am using the Rugged Approach approach for programming in C# and in Python. It just works perfectly! Thanks for the great tutorial. Till now, I worked with many bricklets, but each of a different type. For this case, the approach and code in the tutorial works like a charm. Question: But what would be the best-practice, if you have several bricklets of the same type? Of course, I could use the UID of the individual bricklets to make the differentiation of the individual bricklets. But I would like to avoid the usage of the UID in Rugged Approach for several reasons: Lost of the very generic procedure of the Rugged Approach introducing somehow hard-coded UIDs of bricklet. Incompatibility of several installations of hardware having different UIDs. In the specific application I am working on, the bricklets are connected with a HAT Brick. Question: Is there a possibility to avoid the UIDs? Could I use the information of the ports were each of the bricklet is connected to? In this case, I have to make sure, that each bricklet is connected with a well defined port. An approach which could be realistic. The information of the port connected to would be based on the return value of the get_identity() function of each bricklet. If I would use the UIDs, is it reasonable/possible to change the UIDs of the individual bricklets to have the same UIDs of the bricklets in each identical installation of the hardware. Looking forward to any ideas and suggestions. Cheers, Yvo

Dear List I have to use the 5V power-supply of the HAT Brick additionally to the 5-28V DC-input. But for constructive reasons (no available space), I cannot use an USB-connectors. Question: Is there a possibility / location to sold a cable directly onto the HAT Brick? With soldering directly a cable, I could use the additional power-supply (which I have to use for several reasons additionally to the 5-28V DC-input, see https://www.tinkerunity.org/topic/11345-hat-brick-und-strompi-3-mögliche-konflikte-bei-serieller-kommunikation-respektive-problem-bei-konfiguration-von-strompi-3/ ) even within the very small space available where the RPi and HAT are installed. Looking forward to any ideas and suggestions. Cheers, Yvo

Das ist in der Tat sehr merkwürdig. Ich habe alles nochmals geprüft und vor allem die Pole des PowerSupply (siehe Foto). Da sehe ich keinen Fehler meines Erachtens. Oder mache ich etwas falsch?

Kein Problem. Ich bin leider ein Elektronik-Analphabet. Folgendes ist gemessen: In der blauen Verbindung messe ich in allen Schaltzuständen 24V (also wie PowerSupply).