Pymesh updates

[catalin]

Hi community 🙌

I want to share with you the Pymesh (LoRa Mesh) current development and plans; last release of Pymesh is in v1.20.0.rc7
For starting, this is my Pymesh presentation(workshop) done at TTN Conf Jan 2019 Amsterdam; if you have any questions 🗣
As I've said in a previous mail, currently I'm working on the Border Router feature, I try to explain in a nice micropy script, basically how Pymesh data can be exposed outside of mesh, on Wifi/BLE/Cellular to the ☁.
Not to forget the 📕 were copied here: https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh.html and https://docs.pycom.io/tutorials/lora/lora-mesh.html with a disclaimer, as Pymesh is included just in RC (development) releases.
But, no worries, 😅 we'll include it in the first official stable.
We're planning in releasing firmware releases with and without Pymesh, due to relatively large (~200KB) code-size.
I'm working at the road-plan for further Pymesh features.
Long-term plan is exposing more openthread features, make tons of tests (lots of nodes, distance); connect Pymesh with Pybytes, optimise power-consumption, security for private Pymesh, profile some KPI (data able to be sent over Pymesh), and of course share all plans with community (basically I will open-source the micropy scripts presented in workshop, have some articles to explain all use-cases).
Just let me know your thoughts, about the further projects, and we could include requirements into official development.

[jclo13]

Hello, @catalin, I have the same error, whit the FW 1.20.2.rc11, for pymesh, have you solved it?.

Thank you in advance.

[chrisso]

@craigzych
I get this in the office as well with a mixture of 2 x Fipy and 3 x Lopy4.
Also found when driving around doing some range testing, it didnt always rejoin the mesh when in range as I would have expected it to do.

[craigzych]

Curious if anyone has seen this behaviour.
I have 4 fipy devices.

Using the simple example modified for USA, I had all 4 nodes join last night. I left them plugged in overnight to test if they would all still be connected in the morning. Last night I had one Magenta and 3 green as I'd expect. This morning all 4 were blue meaning they had segmented into 4 separate networks.
Now this morning I can occasionally get 2 to join after resets but they just want to stay separated.
pymesh_config = {'ble_api': True, 'autostart': True, 'debug': 5, 'LoRa': {'sf': 7, 'region': 8, 'freq': 915000000, 'bandwidth': 2}, 'ble_name_prefix': 'PyGo ', 'Pymesh': {'key': '112233'}}

Have you seen this?

[catalin]

ok @CAPKE, thanks a lot! mode=LoRa.LORAWAN is a mistake, it should have been mode=LoRa.LORA.

A pre-requisite of the Pymesh is that all the nodes (that want to be part of the same mesh network) should be initialised on the same LoRa settings (band, frequency, spreading factor, bandwidth) and master key.

[CAPKE]

@catalin Hi Catalin,

I found a other issue at the https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh/#class-network-lora-pymesh-key-masterkey example:

The constructor class network.LoRa(id=0, …) without the params bandwidth and sf will not work correctly (no neighbors will be found).

Please change to:
lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, frequency = 863000000, bandwidth=LoRa.BW_125KHZ, sf=7)

[catalin]

hi all,

Few updates:

1. the LoRa.Mesh() class documentation issue, was fixed here, so there's no class name Pymesh
2. the repository pymesh_apps was deleted as the information was redundant:

• releases are released thru licensing process
• scripts and mobile app are https://github.com/pycom/pycom-libraries/tree/master/pymesh

[catalin]

Thanks @CAPKE for spotting that documentation problem. The subclass name is Mesh(), not Pymesh() 😕.
I've made a wrong replace-all in docs.

[CAPKE]

@catalin I updated my LoPy4 and FiPy with the firmware LoPy4.tar.gz and FiPy.tar.gz.
On both devices, I successfully tested the example https://docs.pycom.io/pymesh/simple-example/.

But if I try out the following code:

import ubinascii
from network import LoRa

lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)
masterkey = ubinascii.unhexlify("112233")
pymesh = lora.Pymesh(key=masterkey)

See https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh/#class-network-lora-pymesh-key-masterkey

I get the error message:

Traceback (most recent call last):
  File "main.py", line 19, in <module>
AttributeError: 'LoRa' object has no attribute 'Pymesh'
Pycom MicroPython 1.20.1.r1 [v1.11-7c63158e0] on 2019-10-22; FiPy with ESP32

I'm currently not sure when to use which PyMesh-lib?

[catalin]

As mentioned earlier, the official release process is in this topic.

[catalin]

@kodarn Yes, you can use directly mesh_interface.py, but make sure you initialise it as in pymesh.py.
The idea was that the pymesh.py is the API level, but you can just use it as it fits your needs.

[kodarn]

@catalin Perhaps I am misunderstanding things since I was thinking of PyMesh being the Mesh Network. But PyMesh is not that. Instead, PyMesh seems to be more of a wrapper to the Mesh Network enabling BLE/Configuration/CLI stuff?

So if I'm interested in building applications with the Pycom Mesh Network API, and not interested in the Bluetooth & CLI stuff, I should use the mesh_interface.py api?

[catalin]

@kodarn good question, so it seems to be both, which is not clear design, right? Just to mention, there are also threads started for BLE-RPC part.
One idea would be, in the configuration file to have a parameter to enable/disable CLI (also for the other application features).

Or how would you like to use pymesh library? What would you modify?

[kodarn]

@catalin Thanks for updating the documentation!

One question: Do you consider lib/pymesh.py to be an api or an application? To my understanding, it spawn's an interactive CLI shell, right? so should it really be a part of /lib ?

[catalin]

Hi all,

The Pymesh docs were updated: https://docs.pycom.io/pymesh/ explaining the frozen library API, BLE RPC, the CLI and the Border Router example.
It should work with the firmware from https://github.com/pycom/pymesh_apps/tree/master/custom_fw_bin

@CAPKE So, you're having the corresponding firmware Fipy and Lopy from here, so the 2 devices should create a Mesh network. Probably they're not compatible with the older Mesh created by LoPy-1.20.0.rc7.tar.gz because the masterkey is different. Initially I've used some default masterkey, now it can be set here and the default one is specified here in docs.
Anyway, you could find the masterkey with command:

# as test, the masterkey can be printed
>>> print("masterkey:", pymesh.cli("masterkey"))
masterkey: 11223300000000000000000000000000

[ricardolima]

@CAPKE
Hi, it discover indirectly neighbor too? Thank you

[CAPKE]

@catalin: I'm using the https://github.com/pycom/pymesh_apps/blob/master/custom_fw_bin/LoPy4.tar.gz on two devices (LoPy4 and FiPy) , but these both devices can not find a neighbor!
Another 4 LoPy modules with firmware LoPy-1.20.0.rc7.tar.gz work perfectly in parallel.

[Danne]

@catalin Thanks a lot!

This allows my project to continue, and I look forward to check out the app!

[kodarn]

@catalin That erase_all thing resolved my problems. Flash'ing your custom LoPy4-firmware now works, and your updated pymesh_micropy_scripts/main.py example starts out of the box :-)

[catalin]

Thanks to @Danne I was able to debug the problem.

Apparently, there's a more general problem, so before using this Pymesh firmware, you should first erase all your board (Fipy or Lopy4) using the cli version of the Firmware Update Tool, so please navigate where this app was installed (search for pycom-fwtool-cli executable) and execute:

pycom-fwtool-cli -p <PORT> erase_all

Next, flash the Pymesh binary can be flashed using the normal Firmware Update Tool.

Also, fixed a small bug in main.py.