aiko_engine_mp
aiko_engine_mp copied to clipboard
geekscape
Improved WS2812B support, fixed library import from 2 different trees, added demo to control neopixels with on/off and brightness control from tux touch pads
I'll push my updated version. If you have this working, please let me know if you can figure out why setting up dim values from MQTT, affects the brightness of leds also toggled via MQTT, but not when the LEDs are set by led.pixel(color, i, True)
@garthk please have a look at the latest version I just pushed. I need to find out why set title isn't working (thankfully print over serial does), and more surprisingly why I get a different value for dim whether I set it from
I was discussing this with @geekscape : my current code outputs this: loop3: 0.1 Dim: 0.1 Dim: 0.6 Dim: 0.1 loop1: 0.1
the middle 'dim 0.6' happens because I sent this MQTT: sauron:~# mosquitto_pub -h 101.181.46.180 -t public/esp32_X/0/in -m "(led:dim 0.6)" sauron:~# mosquitto_pub -h 101.181.46.180 -t public/esp32_X/0/in -m "(led:debug)"
so, dim has 2 values depending on where it's set from.
Interesting repl sees the version that is set by MQTT:
from lib.aiko import led; locals()["aiko"].led.dim;globals()["aiko"].led.dim;led.print_dim() 0.6 0.6 Dim: 0.1
Does this make sense to you Garth?
ok, I managed to fix the namespace problem I could tell was there the entire time @geekscape like I was smelling early on, the MQTT (aiko/net) thread imports aiko/lib/led.py and gets a different version than my code which also imports aiko/lib/net.py from the main thread. As a result, both threads have a different version of the module with a different value of the dim global variable. It is a micropython bug? I don't know. I'm assuming that threads that import modules after the thread was created, do not share the same memory and therefore values than if the import had been done before the thread (like is done for configuration/main.py) See also the comment in https://github.com/geekscape/aiko_engine_mp/pull/32/commits/c7ccdc0fa698ac9077e25ce06b501172f81c0ebf
OMG, I couldn't get setting the title working either and I found out that
from lib.aiko import led,oled
is not the same as
from aiko import led,oled
They both work, but the first one creates a different namespace for all global variables, while he 2nd one does not and the global variables are shared between threads. Is that an obscure bug, or WAI?
@geekscape I should add that the default files use both interchangeably, when mixing them, in fact introduces this very unclear bug I hit: lib/aiko/led.py says: # from lib.aiko import led lib/aiko/oled.py says: # import aiko.oled
Oh, of course. sys.path is ['', '/lib']. You're getting literally two copies of the same module: one loaded via 'lib', the other via ''. For any module with code, it's being run twice.
Ha! Saved myself a bunch of time explaining it: it's already described as the double import trap in an article explaining how Python module resolution works.
If we remove '' from sys.path, we won't be able to reach applications, configuration, examples, plugins et al nor the built in or frozen modules. If we remove 'lib' it'll be messy… I think it's going to be easiest just not ever importing beginning with lib.
Yes, thanks for confirming what too me way too long to find out. I can see sys.path being helpful, but here is made things much much worse. Even Andy used both forms, causing an unsafe mix, and ultimately bugs like the ones I ended up hitting. Oh well, despite the price, I learned something about python :)
@garthk I think I fixed all the issues, it works as intended now. Demo; https://www.youtube.com/watch?v=sNQQ8SSOUU0
Would you mind trying it out to see if it works for you?
@geekscape the code should be good for review and merge if it looks good to you
Thanks for the review. Let's now see what @geekscape says since I think he wants to personally review stuff like that before it goes in :)