Hi,
I'm new to the mailing list, so please be patient.
I've been using meshctl to provision/configure a group of
mesh nodes.
There does not seem to be a mechanism in meshctl to send
model messages to group addresses or virtual addresses.
As an example, consider the simple OnOff model. I can
configure the subscription for an OnOff model with a group
address. However, the meshctl onoff command will not work
with a group address set for the onoff target.
I have modified the cmd_set() function in onoff-model.c by
removing the node_find_by_addr(target) check and this works
fine. Obviously, that only works for the OnOff model. I'd
happily submit a patch for that model, but that doesn't seem
to be a very good general solution.
So is meshctl the right (only) tool to use on Linux?
Is there a newer tool that is planned or under development?
regards,
mike
Hi Michael,
On Sat, 2020-02-15 at 13:20 -0500, Michael N. Moran wrote:
> I've been using meshctl to provision/configure a group of
> mesh nodes.
First off, don't use meshctl for work going forward, unless for some reason you *require* GATT support. Mesh
is designed to primarily be an Advertising based system, and so all current work is being done on the
bluetooth-meshd daemon, which does not yet have GATT support.
We currently have a pretty robust solution based on:
1. Run mesh/bluetooth-meshd as root
1.1 You may need to first install, *or* copy
mesh/bluetooth-mesh.conf --> /etc/dbus-1/system.d/bluetooth-mesh.conf
1.2 Make sure mesh/bluetooth-meshd has a dedicated v4.0 or
better controller. This can be done by stopping bluetoothd,
or by having a 2nd controller in the system and making sure
that in /etc/bluetooth/main.conf, AutoEnable=false
1.3 reboot
2. Run tools/mesh-cfgclient
> There does not seem to be a mechanism in meshctl to send
> model messages to group addresses or virtual addresses.
>
> As an example, consider the simple OnOff model. I can
> configure the subscription for an OnOff model with a group
> address. However, the meshctl onoff command will not work
> with a group address set for the onoff target.
>
> I have modified the cmd_set() function in onoff-model.c by
> removing the node_find_by_addr(target) check and this works
> fine. Obviously, that only works for the OnOff model. I'd
> happily submit a patch for that model, but that doesn't seem
> to be a very good general solution.
>
> So is meshctl the right (only) tool to use on Linux?
> Is there a newer tool that is planned or under development?
See above, and use the tip of the repository (currently at v5.53)
>
> regards,
> mike
Hi Brian,
Thanks for the quick reply.
On 2/15/20 2:50 PM, Gix, Brian wrote:
> Hi Michael,
> On Sat, 2020-02-15 at 13:20 -0500, Michael N. Moran wrote:
>> I've been using meshctl to provision/configure a group of
>> mesh nodes.
>
> First off, don't use meshctl for work going forward, unless for some reason you *require* GATT support. Mesh
> is designed to primarily be an Advertising based system, and so all current work is being done on the
> bluetooth-meshd daemon, which does not yet have GATT support.
I've been working on a mesh stack implementation since June,
so I have a pretty good understanding of the protocol.
I started the development using a now defunct Linux meshd
project that used PB-ADV for provisioning. It never had much
mesh support beyond provisioning.
Later, I moved to meshctl after I implemented Mesh
Provisioning and Mesh Proxy over GATT.
More recently I've been using various silicon vendor Android
based mesh apps, which all use GATT exclusively.
At the moment, I'm working on the LPN and Friend support.
> We currently have a pretty robust solution based on:
>
> 1. Run mesh/bluetooth-meshd as root
> 1.1 You may need to first install, *or* copy
> mesh/bluetooth-mesh.conf --> /etc/dbus-1/system.d/bluetooth-mesh.conf
>
> 1.2 Make sure mesh/bluetooth-meshd has a dedicated v4.0 or
> better controller. This can be done by stopping bluetoothd,
> or by having a 2nd controller in the system and making sure
> that in /etc/bluetooth/main.conf, AutoEnable=false
>
> 1.3 reboot
>
> 2. Run tools/mesh-cfgclient
>
OK. I'm currently using bluez-5.50 on some rapberry-pi zero
w unis with in a Yocto build. I use one pi to run meshctl.
Obviously, bluez has changed since I started. :-)
>> There does not seem to be a mechanism in meshctl to send
>> model messages to group addresses or virtual addresses.
>>
>> As an example, consider the simple OnOff model. I can
>> configure the subscription for an OnOff model with a group
>> address. However, the meshctl onoff command will not work
>> with a group address set for the onoff target.
>>
>> I have modified the cmd_set() function in onoff-model.c by
>> removing the node_find_by_addr(target) check and this works
>> fine. Obviously, that only works for the OnOff model. I'd
>> happily submit a patch for that model, but that doesn't seem
>> to be a very good general solution.
>>
>> So is meshctl the right (only) tool to use on Linux?
>> Is there a newer tool that is planned or under development?
>
> See above, and use the tip of the repository (currently at v5.53)
I cloned the tip and have poked around a bit. However, I
don't see any OnOff model work other than the
tools/mesh-gatt/onoff-model.c, which does not *appear* to be
a part of the mesh-cfgclient build.
I'm probably missing something.
How is this supported in mesh-cfgclient?
Hi Michael,
> I'm probably missing something.
> How is this supported in mesh-cfgclient?
mesh-cfgclient only has a Config Client model. It can be used as a starting point to write an On/Off client or server, or you can also look in test/test-mesh to find an example of a python implementation of on/off client and server.
—Brian
Hi Brian,
On 2/16/20 10:17 AM, Gix, Brian wrote:
>> I'm probably missing something.
>> How is this supported in mesh-cfgclient?
>
> mesh-cfgclient only has a Config Client model. It can be used as a starting point to write an On/Off client or server, or you can also look in test/test-mesh to find an example of a python implementation of on/off client and server.
Ah... the test-mesh python code is interesting.
It appears that test-mesh application is used to add a new
device/node to the mesh daemon via dbus, with its own cli
interface.
That new device/node can subsequently be provisioned and
configured using mesh-cfgclient.
Once provisioning is completed the test-mesh On/Off Client
menu commands can be used to send messages to any
destination address.
Thank you,
mike