Currently we’re trying to implement the following:
Soft shutdown to the Pi
Followed by a hard shutdown to ensure that the Pi is off AND the Cellular Base HAT is OFF
I saw that the hard_power_off method has been removed from the python API. Does that mean hard power off is no longer supported? And if so, how should we power down the Base HAT to make sure it doesn’t consume energy over night?
What I think may suit the functionality you are looking to achieve is: power_api.py: set_edm_status()
def set_edm_status(self, status, timeout=RESPONSE_DELAY):
"""
Function for setting easy deployment mode status. The EDM mode provides ulta power saving
by disabling all power output on the HAT including end device (like Raspberry Pi). It can be used
transport and easy deployment purpose. It disables automatically when the power source is plugged to HAT.
Parameters
-----------
status : int
"1" for ENABLED, "2" for DISABLED
timeout : int (optional)
timeout while receiving the response (default is RESPONSE_DELAY)
Returns
-------
result : int
"1" for SET OK, "2" for SET FAILED
"""
command.create_set_command(
command.PROTOCOL_COMMAND_SET_EASY_DEPLOYMENT_MODE, status, 1
)
command.send_command()
delay_ms(timeout)
raw = command.receive_command(COMMAND_SIZE_FOR_UINT8)
status = raw[PROTOCOL_HEADER_SIZE]
return status
This cuts the power to connected devices, I’m not 100% certain about this, so you’ll need to test it.
Unfortunately I’ve only just started working with these devices today so I’m not sure what happens when you plug it in. I’ll be running some tests later so if I remember I’ll give it a go!
A more pressing issue I expect you’d face is that the soft_shutdown will power down the RPi and you’d have no device to issue the emd_mode (unless you’re confident in I2C comms and GMM programming that is), what may be better is to send a halt command to the system (effectively closes the system to the lowest running level) and then issuing the emd_mode.
In addition to this, it may well be the case that the emd_mode doesn’t change anything if the device is still charging.
From what I’ve learned whilst trawling the rest of the discussions here is that the hard_shutdown function that was removed actually turned off the UPS Hat in addition to all of the peripherals attached, thus making the whole system inaccessible without a power cycle!.. From this I gather that the schedule ‘on’ event would theoretically work
Sorry to rope you in on this, but I really think the hard shutdown needs to be put back into the python API. This was a short-sighted decision that ignores a common use case. It is the only way to get the board to shutdown as completely as possible. EDM is not good enough.
When calling hard_power_off, rpi shuts down and there is no way to remotely turn on Raspberry pi. For this reason, this method removed. You can do this by creating a hard_power_off event with a 10-second interval(only once).
I know this, and this is my desired behavior. The power consumption during soft power off is much higher and not at all acceptable.
I’d really rather not have to create an event. I need an IMMEDIATE shutdown. I think a better solution than removing this function would be, simply, to note this caveat.
@ensar perhaps there could be a requirement that there is a START event on the power hat so that it will be brought back online at some point in the future? That way you don’t get locked out. That would be very helpful for us.
I agree that this is a good option, but I vehemently disagree that it should be a requirement. In my case, a button press is the desired way to regain access. I do not, ever, want it to come on when it does not have external power connected.
As a matter of fact, the only thing that I want the HAT to do during this time is keep the RTC running, no watchdogs, no housekeeping, just the clock.
The only things I use the HAT for are to shut it down gracefully when power is removed and to maintain the RTC, nothing else. In my setup, the HAT (and its battery) are never used to power the device for very long when the external power is not connected.
