Alex's Corner - Week 6 - Best Practices for Deployment


  • administrators

    Hi Everyone,

    I will be running the next webinar at 2 pm (BST) Thursday the 18th of May, discussing best practices for deploying Pycom devices. This live stream slightly breaks the usual schedule as the Pytrack livestream was delayed a week.

    The format will be as following:

    • Introduction
    • Discussion about deployment
    • Explanations/Examples

    Please do ask any questions (either here or in the livestream chat), I'll try to answer them live!

    Visit this link next week, on the 18th of May to join in!

    https://www.youtube.com/watch?v=0TQBPYYOPCA

    Cheers,

    Alex



  • @tenspot It's also a convention to write the constant 'variables' in all uppercase.



  • @tenspot have a look at this config.py and this file that uses it.

    Basically the config.py is a .py file where you declare the variables:

    GATEWAY_ID = '11aa334455bb7788'
    
    SERVER = 'router.eu.thethings.network'
    PORT = 1700
    
    NTP = "pool.ntp.org"
    NTP_PERIOD_S = 3600`
    
    WIFI_SSID = 'my-wifi'
    WIFI_PASS = 'my-wifi-password'
    

    Then, if you want to use them in another python file, you import it using:

    import config
    

    After that you can address any variable that you have defined in that config.py file like (for example):

    config.WIFI_SSID
    

    etc



  • Hi Alex,
    Thank you for posting these tutorial videos, I find them very useful.
    You refer to using a configuration file for wifi password, UUID etc., I would be grateful if you would outline the structure of this file as I would like to use this technique, but am unsure how to create such a file.

    Regards,

    Mervyn



  • @PiAir
    You can add or between and fire in both cases :-)
    e.g.

    Pin.IRQ_FALLING | Pin.IRQ_RISING
    

    are there specific use case
    This depend - e.g. how fast signal raisin/falling



  • @livius Ok...but when would I prefer using IRQ_HIGH_LEVEL over IRQ_RISING in an interrupt? Is it just there for redundancy or are there specific use case that would make you use one or the other?



  • @PiAir
    this is about voltage/state indicator
    IRQ_LOW_LEVEL 0
    IRQ_HIGH_LEVEL 1 - 3V3
    IRQ_FALLING - The falling edge of the signal
    IRQ_RISING - The rising edge of the signal



  • OK, last one for this video. You create the interrupt handler using:

    def pin_handler(arg):
    

    From this page I understand that arg contains the Pin object. So I would be able to create one handler that handles interrupts from multiple pins, correct?
    On that page, also Pin.IRQ_LOW_LEVEL and Pin.IRQ_HIGH_LEVEL are mentioned. Would I be able to for example use that so set an interrupt that triggers a funciton if the temperature provided by an DHT11 gets to a low or high level?

    The documentation here is a bit outdated? It states that only the Alarm class and the Pin provide the .callback() method while at least the Bluetooth class also supports it.

    Sorry about all these questions after the livestream itself!



  • Ah, you explain the PWRON_RESET and SOFT_RESET later. Solves one question.
    Still not sure why I wouldn't want to init the wifi in case of SOFT_RESET?



  • A little later you look at

            while not wlan.isconnected():
                machine.idle() # save power while waiting
    

    Since the topic is deployment:
    This loop caused me problems once, because I used it on one of my LoPy devices. At home, there was no problem. But then I took the node with me and had to unplug it's power and reboot it while being no where near the range of my WiFi network...

    I now use this code in my boot.py:

    nets = wlan.scan()
    
    for net in nets:    
        if net.ssid == config.WIFI_SSID:
            if not wlan.isconnected():
                wlan.connect(config.WIFI_SSID, auth=(WLAN.WPA2, config.WIFI_PASS), timeout=5000)
            while not wlan.isconnected():
                machine.idle() # save power while waiting
            pycom.rgbled(0x007f00) # green
            time.sleep(3)
            pycom.rgbled(0)
            break
    

    (forgot where I've seen this, can't imagine I made it up myself)
    This then checks to see if there is a WiFi network available with the same SSID as the one in the config.py file. If so, it connects and shows the green LED for 3 seconds to indicate me that it has connected.
    So, if I start the node outside of the reach of my WiFi network it no longer tries to connect.



  • In the livestream you mention that

    if machine.reset_cause() != machine.SOFT_RESET:
    

    checks for a crash. But after a crash wouldn't you still want to setup the wifi?

    If I look at this list, it lists

    • machine.PWRON_RESET
    • machine.HARD_RESET
    • machine.WDT_RESET
    • machine.DEEPSLEEP_RESET
    • machine.SOFT_RESET

    But without description of what could cause any of these and also without examples of what I would want to different for each of these.
    The Pycom documentation only lists:

    • machine.PWRON_RESET
    • machine.SOFT_RESET

    Again without any further information.

    Could you explain these a bit more and possible give examples of how you would want to handle them in boot.py ?



  • It was. :)
    (or is it "It is" ?)



  • @bucknall
    I am between timezones at the moment but 18th of May was yesterday?
    Sorry ignore... got confused because I saw this posted an hour ago, but the stream was yesterday..


Log in to reply
 

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.