HAT-Brick und StromPi-3: Mögliche Konflikte bei serieller Kommunikation? Respektive Problem bei Konfiguration von StromPi-3

[yvo]

Guten Tag Form

Für ein Projekt verwende ich das HAT Brick entsprechend zusammen mit einem RaspberryPi 3B+. Für die spannungsfreie Stromversorgung benutze ich den StromPi 3 in Kombination mit der Batterie-Einheit für StromPI 3.

Zentral dabei ist die serielle Message vom StromPi 3, dass die Stromhauptversorgung unterbrochen ist und die Einheit auf der Batterie läuft. Diese Message wird von einem Python-Programm genutzt, die eigentliche Sensor-Applikation mit Tinkerforge-Bricklets kontrolliert zu beenden, bevor der RaspberryPi 3B+ via dem StromPi 3 runter gefahren wird.

Im ersten Prototypen hat es soweit funktioniert:

• Der StromPi 3 reagiert wie konfiguriert:
  • Message wird ausgesendet, wenn Hauptstrom weg ist.
  • Die ganze Einheit läuft zuverlässig weiter.
  • Die ganze Einheit wird nach den definierten 30 Sekunden runtergefahren.
• Das HAT Brick kann mit den Bricklets kommunizieren:
  • Soweit keine Einschränkungen gefunden.
• Über die serielle Schnittstelle im Python-Programm kann die Powerfail-Message entgegengenommen werden.

Soweit so gut.

Was aber ein Problem macht, ist die Konfiguration des StromPi 3:

• Wenn das HAT Brick montiert ist, kann die Konfigurationssoftware vom StromPi 3 nicht gestartet werden.
• Hier kommt es zu einem Konflikt auf der seriellen Schnittstelle.

Sobald das HAT Brick demontiert ist, können die Konfigurationen vom StromPi 3 problemlos gemacht werden. Diese sind dann nach dem Reboot und Montage des HAT Brick auch aktiv.

Wenn der RaspberryPi 3B+ mit dem StromPi 3, ohne HAT Brick aber mit einem Master-Brick via USB verwendet wird, treten die oben beschriebenen Probleme nicht auf:

• Ich vermute, dass dann die Kommunikation ausschliesslich über den USB-Bus läuft, oder?

Frage:

• Kennt sich jemand mit dem StromPi 3 in Kombination mit dem HAT Brick aus?
• Respektive, hat jemand schon ähnliche Erfahrungen gemacht?

Freue mich auf jeden Hinweis.

Mit den besten Grüssen,

Yvo

[Superp]

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

bearbeitet February 21, 2023 at 10:21 von Superp

[yvo]

Hi Superp

Thank you very much for the quick replay and the proposed solution 2. Eliminate the StromPi. This sounds very promising!

I checked the API of the HAT-brick again. But I am not sure yet, if I am able to implement my needs:

1. HAT registers a drop of the DC-voltage below threshold:
   1. That should be OK.
2. Script stops the execution of the application immediately:
   1. That should be OK.
3. Script shutdowns the RaspberryPi and the attached HAT:
   1. Not sure how to do. Shall I call

      os.system("sudo shutdown now")

Question:

• Will the mentioned command be enough to shutdown the Raspberry and all attached bricklets?

As far as I understood the description of the API of the HAT, I will be able to send to sleep the HAT and cut the power-supply of the Pi and the bricklets. But I will not be able to run an entire shutdown (e.g. power_off_duration = 0).

Question:

• Do you have a different great suggestion?

Advantage of the StromPi is, that you are able to configure an entire shutdown of the system after a defined time-span.

Looking forward to any suggestions.

Cheers,

Yvo

[Superp]

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.

[yvo]

Hi Superp

Thank you again for your extensive feedback. I am not surprised, that you are confused. Sorry for my imprecise description. I try to explain it in more detail (especially if someone else comes up with a similar question).

Basically, the approach is used for a "rocker -switch"-only measure-device:

• As soon as a person switches the device on, the Pi starts and a Python-software runs the measurements.
• As soon as the person switches the device off, the measurements have to stop, all the resources have to be closed, the log has to be written and the Pi has to stop.

The start works ok. I am using services to start the software after powering the Pi. The stop is what still worries me.

The power-supply of the device is done by batteries (about 22V).

When I understand your replay correctly, I have to take the following steps:

1. Running the measurements.
2. In parallel, I monitor the power-supply of the HAT (e.g. by using callbacks).
3. As soon as the power-supply drops below a defined voltage (e.g. 10V), I assume that the person switched the device of.
4. The software runs the final operations, such as logging and closing all resources.
5. As soon as all operations are terminated, the software calls the OS and initiates a shutdown.
6. Additionally, the software calls the HAT-API function set_sleep_mode with the parameters you suggested (the value for the power_off_duration taking 136 year is ok 😇
7. The software stops running.
8. After the given delays, everything falls asleep and the device consumes only a minimum of power.

As soon as a person switches the device back on, the Pi starts and using the services, the entire setup runs again. Isn't it?

What do you think? Was I able to summarize more or less your proposal of the previous post?

Looking forward to any hints and suggestions.

Cheers,

Yvo

[Superp]

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.