4. Where is the WiFi config held?

Where is the WiFi config held?

  • D

    I want to access the pre-existing WiFi config from micropython, the one you setup with M5burner.

    On 1.4.5, on the M5StickC, the SSID + password are stored in apps/config.json. This is cool, as I don't have to hard-code it into my apps.

    On 1.5.1, on the Core/Gray, there does not appear to be any equivalent file, yet it still knows the information. How do I access it?

    I tried wifi_history = machine.nvs_getstr("history") from WifiCfg.py, but machine doesn't have nvs_getstr().

    Is there any way to get this now? I really don't want to go back to hard-coding!

    1
  • D

    Poking around a bit:

    wifiCfg.deviceCfg.get_wifi()
['fbi covert AP', 'letmein']

wifiCfg.deviceCfg.wifi_read_from_flash()
['not the cia', 'really']

    This actually sort of makes sense in that I used not the cia with m5burner, but I called doConnect once with 'fbi covert AP` hard-coded.

    Reflashing back to 1.4.5, I see that it is not the same:

    >>> wifiCfg.deviceCfg.wifi_read_from_flash()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute deviceCfg'

>>> wifiCfg.wifi_read_from_flash()
['not the cia', 'really']

    Ugh.

    1.5.2 is the same as 1.5.1 though.

    0
  • M

    May I ask how you found out about the methods names ?

    I dont think they are up for reading on github right ?

    0
    D
     1 Reply
  • D

    @medy mostly:

    print(dir(wifiCfg))
print(wifiCfg.__dict__())

    I'm sure that someone has written a function that formats all this, recurses, etc, but I usually just do it manually, because there are usually only a few things that make sense to try.

    Also googling for micropython wifiCfg (or whatever), because micropython is not just for M5, and a lot of the code is on the internet. It's not always exactly the same, but it often is, or is close enough to provide hints for more things to look at.

    I'm assuming that you know how to use rshell or some other tool to get to repl so that you can just type in statements as they occur to you, rather than writing a script for every new thing you want to try.

    0
    M
     1 Reply

  • On my core gray, I have a specific code to write my config file myself.
    That way, I always know how to read it back.
    My experiments are available on Github and I used it in several of my videos, for exemple this one on writing and reading this config file.

    It’s in french, but I think the code is simple enough.
    If it’s not the case, I can answer questions.

    0
    M
     1 Reply

  • Alot of the core commands can be found by googling Micropython, Circuit python and Python.
    The M5 Specific apis are proving more elusive and I'm doing my best to log them in my UIFLow book found in my github.
    https://github.com/Ajb2k3/UIFlowHandbook

    0
  • M

    @dclaar thanks man :D ... I forgot this existed ...
    also no im atm exploring options to improve debugging on m5stack ...
    if you have any advice please let me know ...

    Basicly I just want some way where I can run the code on devices with no screen .. and show me the errors .

    I tried mu .. but it doesnt seems to work on m5stack firmware ... same with ampy ... the "ls" command just freezes the prompt and doesnt show the directories -.-...

    the only serial connection I managed so far was via putty..

    Working on a little project to display notifcations on the m5 core devices...
    So maybe I will flash the micropython firmware instead of using uiflow ...
    I like uiflow though .... makes testing & developing stuff very nice

    0
  • M

    @titimoby thanks I figured out how to use mu now with your video

    0
  • D

    Rshell works pretty well, although the newer M5 releases are a lot harder to get into the correct mode, particularly on the atom.

    Uiflow is micropython: I have often written something in uiflow and then switched to the micropython side to see what the python is for a given uiflow thing. And then I can cut and paste into repl.

    For long-term debugging (fails once a day or week), I leave the device connected to putty.

    I have considered adding code that would catch Exception () in the main loop, do a stack trace, and save it into a file so that I don't need it to always be connected, but have never implemented it.

    0