# MicroPython Integration - Low Power Support **URL:** \ **Category:** General\ **Created:** [September 21, 2026, 8:05pm UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044 "2026-09-21T20:05:15Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![kwagyeman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.morsemicro.com/kwagyeman/32/1024_2.png) [@kwagyeman](https://community.morsemicro.com/u/kwagyeman)\ **Post date:** [September 21, 2026, 8:05pm UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/1 "2026-09-21T20:05:15Z")
Hi, I’m working on the OpenMV HaLow camera (MM8108 module on our own shield, mm-iot-sdk 2.12.3 / morselib, custom host: STM32N6 running MicroPython with our own network.HALOW driver over SPI). I’m trying to get low-power wake-on-directed-packet working: the host MCU fully powers down (deep sleep), the MM8108 stays powered and holds the link, and an incoming packet addressed to us wakes the host. Our hardware is already set up for this: the shield keeps the MM8108 powered/un-reset through host deep sleep, and module GPIO8 (BUSY) is wired to the host’s wake pin. Following your community-forum guidance (the WAKE\_ACTION\_GPIO thread), I set MORSE\_CMD\_PARAM\_ID\_WAKE\_ACTION\_GPIO = 8 and …\_PULSE\_MS = 200 (GET confirms both), which should pulse that line on wake. I then drove the standby-offload command family (MORSE\_CMD\_ID\_STANDBY\_MODE, 0x0031) directly through our command passthrough. Every command is accepted (status = 0) and the association stays up: - SET\_CONFIG — accepted with the V1 layout (cmd=2); cmd=7/V4 returns -32768 - SET\_WAKE\_FILTER (cmd=4), ENTER (cmd=1, with the real BSSID + is\_umac\_controlled=1), EXIT (cmd=0) The problem: after ENTER + host deep sleep, sending a directed UDP packet to the STA’s IP:port does not wake the host — the wake line never pulses. I tried both a zeroed and the real monitor\_bssid. I also saw in your release notes that “Standby and Offload features of the MMWLAN API are in development and may not be fully functional,” so I want to confirm status before I chase config. Questions: 1. Is standby-offload expected to be functional on MM8108 + morselib 2.12.3? Any known limitations or a target release where it’s finalized? 2. SET\_WAKE\_FILTER: what is the offset reference point (start of 802.11 frame? de-encapsulated IP frame?), and how do we express “wake on packets addressed to our IP / a specific UDP port”? A concrete example filter would help enormously. 3. SET\_CONFIG (V1): field semantics — especially src\_ip/dst\_ip byte order, the roles of notify\_period\_s / deep\_sleep\_period\_s, and whether SET\_STATUS\_PAYLOAD and/or DHCP-offload must be configured first. Which config version should we use for 2.12.3, and its exact struct? 4. is\_umac\_controlled: what does the host supply vs. the chip when this is true vs. false? Is monitor\_bssid required, and in which mode? 5. Host wake in standby: beyond setting WAKE\_ACTION\_GPIO (param 8), is anything else required for the chip to actually toggle the host wake line when a wake-filter packet arrives? 6. Host re-attach after full power-down: our host loses RAM in deep sleep and reboots. What’s the intended flow to resume the standby session and learn the wake reason? (We see the wpa\_supplicant standby\_session\_dir persistence — is there an equivalent path for a bare-morselib host that isn’t using your wpa\_supplicant integration?) 7. Happy to share a minimal reproduction or logs. This is the last piece for a genuinely low-power HaLow camera, so any guidance is much appreciated. Here’s the PR for MicroPython we are working through: [https://github.com/micropython/micropython/pull/19617](https://github.com/micropython/micropython/pull/19617) ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [September 22, 2026, 11:49am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/2 "2026-09-22T11:49:45Z")
Hi @kwagyeman We marked standby/offload APIs as deprecated in [mm-iot-sdk 2.10](https://github.com/MorseMicro/mm-iot-sdk/blob/2.10.4/framework/morselib/include/mmwlan.h#L1437-L1446) and removed the APIs in release 2.11. At the time the implementation was not production ready (on either SDK nor FW side) and we had several outstanding issues that outweighed the benefit. I believe the FW team have recently picked up several of the offload features to improve the reliability and performance, but it would be several months before that’s made available to the IoT SDK and there’s no plan on the roadmap for us to add support for offload. The operating model we support today is like on the EKH05 where we run the MCU as normal and have it drop into STOP2 deep sleep when there is no work to do, and we wake from timers elapsing or the SPI interrupt or busy pin being raised by the chip. Depending on your systems traffic profile you can look into various low power modes for the chip such as high DTIM, WNM sleep etc. Cheers ---
**Author:** ![kwagyeman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.morsemicro.com/kwagyeman/32/1024_2.png) [@kwagyeman](https://community.morsemicro.com/u/kwagyeman)\ **Post date:** [September 22, 2026, 5:51pm UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/3 "2026-09-22T17:51:29Z")
Hi @ldennis , So, I was able to get the device to wakeup on the BUSY pin for all traffic on the network. However, I was not able to get the device to filter the packets such that wakeup would only be on something addresses to us. Like, UDP broadcasts were waking us up… So, is there a solution for this? Like only wakeup on UDP/TCP traffic for our IP address? Right now, only BUSY is tied to our wakeup pin, but, I can modify our hardware such that IRQ wakes us up too in deepsleep mode. ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [September 22, 2026, 9:04pm UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/4 "2026-09-22T21:04:21Z")
Traffic is filtered by mac address not IP address and I don’t believe there’s a way to filter broadcast traffic out, technically broadcast traffic is addressed to to the host. As an FYI, we did have a FW bug where in some instances traffic not for us was passed up. That was fixed in FW2.0 which is available in the IoT SDK 2.13.1 - it would be worth updating either way as FW2.0 had several big improvements. I checked the release notes, seems like we missed adding some of this detail, will try do better next time! ---
**Author:** ![kwagyeman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.morsemicro.com/kwagyeman/32/1024_2.png) [@kwagyeman](https://community.morsemicro.com/u/kwagyeman)\ **Post date:** [September 22, 2026, 9:42pm UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/5 "2026-09-22T21:42:30Z")
We are using the latest firmware. > Traffic is filtered by mac address not IP address and I don’t believe there’s a way to filter broadcast traffic out, technically broadcast traffic is addressed to to the host. You guys need to get that on your roadmap. I’ll be starting MicroPython integration with Newracom after I finish with MorseMicro. I was informed they have this capability. It’s rather important as it allows push notifications from a server to wakeup a device. Quite essential for a battery powered device being able to be waked remotely. ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [September 29, 2026, 2:19am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/6 "2026-09-29T02:19:09Z")
> [@kwagyeman](#): > > We are using the latest firmware. In your original post you indicated you were using SDK 2.12. Does that mean you have since updated to 2.13? > [@kwagyeman](#): > > You guys need to get that on your roadmap. I don’t have a timeline to quote, but I’ve heard this is in the works 😉 > [@kwagyeman](#): > > It’s rather important as it allows push notifications from a server to wakeup a device. I’m a little confused here, how does **filtering out** broadcast traffic help a server wake a device? On a separate note, if you’re having power issues due to unwanted broadcast traffic, you can update the AP configuration to filter a lot of this out and minimise the amount of broadcast traffic floating around ---
**Author:** ![kwagyeman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.morsemicro.com/kwagyeman/32/1024_2.png) [@kwagyeman](https://community.morsemicro.com/u/kwagyeman)\ **Post date:** [September 29, 2026, 5:42am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/7 "2026-09-29T05:42:09Z")
The broadcast traffic just wakes the device with each broadcast packet. However, what I want to be able to do is have the device wake up when it receives a non-broadcast packet addressed to it. I was able to get it working as mentioned and waking up on each packet received, but, not on only non-broadcast packets. ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [September 29, 2026, 6:03am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/8 "2026-09-29T06:03:57Z")
Understood - that’s expected behaviour. Your network shouldn’t have that much broadcast traffic, if there’s a high amount of it, it’s best to handle this at the source/gateway. Good to hear there’s good progress happening ---
**Author:** ![kwagyeman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.morsemicro.com/kwagyeman/32/1024_2.png) [@kwagyeman](https://community.morsemicro.com/u/kwagyeman)\ **Post date:** [September 29, 2026, 6:16am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/9 "2026-09-29T06:16:25Z")
Uh, there are always packets moving around. Here’s the PR progress BTW: [https://github.com/micropython/micropython/pull/19617](https://github.com/micropython/micropython/pull/19617) ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [October 2, 2026, 2:02am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/10 "2026-10-02T02:02:24Z")
I had a quick look, nice progress! One thing I noticed is you’re testing against 2.12.3 [mm-halow-driver/lib at main · micropython/mm-halow-driver · GitHub](https://github.com/micropython/mm-halow-driver/tree/main/lib) As before, I would strongly recommend updating to 2.13.1 as there was some significant improvements around the chip incorrectly passing up traffic that is not intended for the host. I wouldn’t be surprised if this is impacting this exact issue you’re observing! [Morse Micro MM-IoT-SDK release 2.13.1 · MorseMicro/mm-iot-sdk@d637247 · GitHub](https://github.com/MorseMicro/mm-iot-sdk/commit/d63724744b9596decf077a791c760319ebcbee05) ---
**Author:** ![kwagyeman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.morsemicro.com/kwagyeman/32/1024_2.png) [@kwagyeman](https://community.morsemicro.com/u/kwagyeman)\ **Post date:** [October 2, 2026, 3:53am UTC](https://community.morsemicro.com/t/micropython-integration-low-power-support/2044/11 "2026-10-02T03:53:10Z")
Okay, will pull that update in.