Features wish list

[jasonriedy]

Shorter term, but already on your plan:

• Sleep & wake-up

Longer term, likely already on your plan:

• OTA updates (via LoRaWAN for our deployment)

Longer term niceties (mostly during development for me, although I have an idea about phoning home via ssh):

• Enterprise WPA support
• Exposing the encryption engine in a way that a Python ssh server/client can use easily.

[daniel]

@jasonriedy thanks for the feedback. Everything you suggest is already on our plan, but we'll add it to the list for better visibility. Regarding:

Exposing the encryption engine in a way that a Python ssh server/client can use easily.

That's already done weeks ago :-)

https://docs.pycom.io/pycom_esp32/library/ucrypto.AES.html

Are you missing anything from the AES API?

Cheers,
Daniel

[jasonriedy]

@daniel Ah! I'll have to try one of the Python ssh implementations next time I can. Assuming they use the same interface, which is what I meant by "easily."

[gertjanvanhethof]

@daniel Non blocking for I2C should be put on top of the wish list.

But if I can add new topics than I would ask you to put full support of TTN as nano-gateway to the list.

[Roosted]

@jasonriedy said in Features wish list:

• Enterprise WPA support

802.11X is the feature i'm really waiting for!
I've seen Wi-Fi marked as 'done' somewhere, but it is not usable in enterprise/educational environments...

For as far as I know 802.11X is supported in the ESP-IDF, so it would 'just' need to be implemented in python - right?

Thanks for steady development pace! :)

[daniel]

Suggested by @alexander :

Use the RGB led to show WiFi/BT connection status among other things.

[livius]

@daniel
if added then should be optional - we use it for self status purposes

[daniel]

if added then should be optional - we use it for self status purposes

Of course. Calling pycom.heartbeat(False) would disable the internal handling of the RGB led.

[JF002]

@gertjanvanhethof said in Features wish list:

@daniel Non blocking for I2C should be put on top of the wish list.

But if I can add new topics than I would ask you to put full support of TTN as nano-gateway to the list.

I second this! I would like to make a LoRaWAN/TTN nano-gateway (I know, it won't be fully compliant with LoRaWAN specification, but from my understanding, it should be possible to use it as a development gateway).

[alexander]

In no particular order:

• Long range WiFi with DSSS @ 1MBit/s (WiPy is advertised with 1km)
• Pulse counter
• Direct hardware access (similar to the examples on Micropython speed), i.e. the Viper code emitter or some other approach to allow high speed digital IO
• Integration with other Micropython ports, staying as compatible as possible
• Deep sleep and timer based wakeup

[lmetcalfe]

@daniel
Priority order

• Sleep/DeepSleep with RTC and RTC memory functions. How environment is preserved during various sleeps.
• Power consumption in various sleep functions - Radios on/ff
• Non Blocking options on peripherals
• bluetooth.get_adv()

[mohpor]

To reiterate others or the original list, (Better be safe than sorry):

• BLE Peripheral (server) of course!
• BLE Peripheral or Central events (connected, subscribed, written, ...)
• Reliable Pin Interrupts
• Deep Sleep with Pin/RTC interrupted wake ups
• RTC
• WiFi 802.11X
• Enable/Disable WiFi/BLE

I know lots of them are on the original list and plan and I hope we will see them in the upcoming releases.

[madsdk]

For me the most critical features I'm missing right now are:

1. Deep sleep with RTC wakeup
2. The ability to disable Wi-Fi and Bluetooth altogether to conserve energy.

[Roosted]

I've been thinking about this for some more. Here is my list:

1. Upstream open source code

Right now, code updates are infrequent (only on version number), and in completely separate fork. This has resulted in very few PR from other developers...
I'm really hesitant to help this uPy development, because it is completely separated from upstream - and I have spoken several other developers that feel the same. We understand the re-licensing might have been necessary because of (for example) LoRa chipset vendor drivers, but probably not all the code - right? If all the core esp32 stuff was merged upstream, free development help might come by itself :)

If help does not come by itself, you guys might set (financial or material) intensives for helping the development. Since you probably have a very good list with features people want, you could set rewards on these features? I know you are looking to hire, and this might be a cheaper & easier alternative?
(If I would study in Eindhoven instead of Delft, I would have applied already...)

2. (802.1X)

I've asked for this before ;)

3. mDNS

mDNS would be really awesome, because you could telnet to 'lopy.local/' instead of scanning the network and telnet'ting into the scanned IP. I guess this is not to hard to implement, as it is all UDP broadcast.

4. SSH instead of telnet

Since we have the hw encryption SSH should be possible? Of course we could all implement this is python, but a C based version would be desirable..

5. Cloud IDE

This one is on the bottom of my list, for a good reason :P (privacy, security, etc, ..)
But still! It would be amazing if your wifi device could connect with some Pycom web IDE to fetch it's (encrypted) python code...

[livius]

i see that this is still not fixed then i add this to the list it is about ADC:
We're working with the ESP32 manufacturer on enabling 12 bits plus the internal attenuation (will enable measurements of up to 4.4V).

https://forum.pycom.io/topic/226/lopy-adcs/8#

[cfaessler]

Some additional wishes from my side:

• Allow to specify port (FPort) for LoRaWAN packages
• Allow confirmed and unconfirmed LoRaWAN packages

[bmarkus]

@cfaessler said in Features wish list:

Some additional wishes from my side:

• Allow to specify port (FPort) for LoRaWAN packages

Is it really missing, port can't be specified per today? In such case I can't use it, as in our network ports allocated to services :(

[daniel]

@bmarkus No, this is already supported. Use the bind() method on a LoRa socket to select the port. For instance s.bind(1) will select port #1 for the socket.

Cheers,
Daniel

[daniel]

Allow confirmed and unconfirmed LoRaWAN packages

This is already supported via socket options.

We are releasing new docs in around 2 hours which will show all this. We'll make an announcement shortly.

[cfaessler]

@daniel Cool thanks!