Date   

What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







Re: Networking API example code

Paul Sokolovsky
 

Hello Patrik,

As we were requested at the TSC meeting to keep the discussion public
at the devel mailing list, please let me re-route this conversation
there.

I also apologize for delayed response - there were public holidays
here. Please see responses below.

On Fri, 27 Apr 2018 15:10:18 +0300
Patrik Flykt <patrik.flykt@...> wrote:

Here is a fairly simple piece of C code that we can use to demonstrate
different networking APIs in Zephyr. It's simple, as the request was
to present the APIs in the Networking Forum next week. Of course a
more realistic example would be much more elegant, but then time
would be spent on deducing the internal flow of the program, which
will not create any more clarity on the matter.
As I mentioned in my previous mail (dated Apr 26,
https://lists.zephyrproject.org/g/devel/topic/examples_for_zstream/18100280),
Zephyr tree includes 5 ready socket examples which demonstrate socket
API from various angles and are known to work. I proposed to use one of
them to demonstrate TLS API approaches.

Your going forward with an adhoc example may leave an impression that
your API can't work with existing examples, and require an artificial
one - which is definitely not true.

But your going with a single-source-file example also hides what the
existing Zephyr socket samples are. They are fully self-contained
(albeit small and "toy") applications with build files included, and
these build files demonstrate thess apps working on both Zephyr and a
reference POSIX system (tested with Linux).

Samples for my Zstream API preserve this continuity. And that's where
your API would have problems. And I hope it's not just me who's keen to
see how you'd resolve that.

So, I hope you had time over the last week also convert one of the
samples at
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets
to your API and test it with both Zephyr and a POSIX system.

Oh, and btw, your sample code had a mistake, so couldn't work as is, I
had to fix it.


I was thinking that the code that is changed/added could be indicated
for example by color, so that the modifications needed by each API and
proposal would be easy to spot. As the code is quite short, it might
even be possible to squeeze the samples on two slide pages each. With
that we then can present the original example socket code below, the
Net App version, Zstream and socket option version in a reasonably
short time in an understandable way.
Fairly speaking, Zstream was at that stage - discussing individual
calls in a presentation-like manner circa beginning of February (and
that was done on github). The way I understood TSC's request is to
prepare 2 more or less real-world samples to compare 2 APIs. I didn't
try to squeeze mine into the presentation slides. I also let Github diff
viewer do the coloring:

https://github.com/pfalcon/zephyr/pull/2/commits/735ba51e56a191e45e9afb7f1a5e221976451e67

This is your sample, as-is from the mail.

https://github.com/pfalcon/zephyr/pull/2/commits/bc1dbb75c5f76739681f9d44eb755f50bb45bc2b

This adds missing connect() call, and build files for Zephyr and POSIX.
This represents a working, testable sample.

https://github.com/pfalcon/zephyr/pull/2/commits/8d2cf8da1fddf946ea8912a327e76d28e05fcaba

This shows the changes required to convert socket-based sample to
Zstream-based sample, still preserving buildability and functioning on
both Zephyr and POSIX.

(Links are valid until git rebase.)


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: STM32 ADC shim

Erwan Gouriou
 

Hi Anthony,

Easiest to start would be to use STM32Cube HAL to implement your shim layer.
If you feel more comfortable with ADC, you might want to use STM32Cube LL
layer, which will help you to implement a more integrated and lightweight driver.

For reference, you can have a look a serial driver, which should be the most
simple one using LL, or PWM for HAL. There are other quite good drivers using
LL or HAL but they are more complex to study.
There is also an on going work to push CAN driver, which uses HAL in a quite
limited way, but could be used to check what is needed to provide for Kconfig
and device tree.

Last, you'll find some examples on how to use STM32Cube LL and HAL APIs
in the packages you can download on www.st.com.

In any way, if you feel blocked or have questions, don't hesitate to ask for support
in this mailing list or provide an early version of your work with [DNM][RFC] tags
(Do Not Merge/Request For Comments) and request for review.

Good luck
Erwan


On 3 May 2018 at 05:43, Anthony Kreft <anthony.kreft@...> wrote:
I'm interested in working on a shim to enable the ADC driver on the STM32. What is the best way to get started with that? Are there any good pull requests I can use as reference? I think most confusing to me are the Kconfig and device tree requirements. If there are known issues with the ADC for STM32 in terms of integrating with the Zephyr driver, please let me know. Thanks for your help.

Regards,
Anthony



STM32 ADC shim

Anthony Kreft <anthony.kreft@...>
 

I'm interested in working on a shim to enable the ADC driver on the STM32. What is the best way to get started with that? Are there any good pull requests I can use as reference? I think most confusing to me are the Kconfig and device tree requirements. If there are known issues with the ADC for STM32 in terms of integrating with the Zephyr driver, please let me know. Thanks for your help.

Regards,
Anthony


Re: Add stm32flash to zephyr_flash_debug.py script

Armando Visconti
 

Hi Marti,

On 05/02/2018 05:43 PM, Marti Bolivar wrote:
Hi Armando,
I had written a post about this to the list, but it seems like it is no longer part of the archives since we moved to groups.io <http://groups.io> (which is unfortunate, I assumed that archives would be preserved).
I reproduce it here for your reference, hope it helps:
Thx very much,

I'll go thru it tomorrow!

Rgds,
Arm


Re: Add stm32flash to zephyr_flash_debug.py script

Marti Bolivar
 

Note also that the documentation for the class you will need to implement is here:


On Wed, May 2, 2018 at 11:43 AM, Marti Bolivar <marti@...> wrote:
Hi Armando,

I had written a post about this to the list, but it seems like it is no longer part of the archives since we moved to groups.io (which is unfortunate, I assumed that archives would be preserved).

I reproduce it here for your reference, hope it helps:

You can specify a flash and debug runner without touching any board files by setting BOARD_FLASH_RUNNER and/or BOARD_DEBUG_RUNNER in the CMake command line when generating a build system.

Here is an example branch, in which I have created a "dummy" runner:


Here is the commit which adds the extra runner, which just prints the command instead of acting on hardware:


Here is an example shell session where the flash and debug runners are set at CMake time and then used later using "ninja flash", "ninja debug", and "ninja debugserver". I have used the nrf52_pca10040 board, but it should work with any board.

plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ cmake -GNinja -DBOARD=nrf52_pca10040 -DBOARD_FLASH_RUNNER=dummy -DBOARD_DEBUG_RUNNER=dummy ..
CMake Deprecation Warning at /home/mbolivar/src/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:2 (include)


-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4") 
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.11.99
[snip]
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mbolivar/src/zephyr/samples/hello_world/build


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja
[1/118] Generating always_rebuild
Building for board nrf52_pca10040
[113/118] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       44732 B       512 KB      8.53%
            SRAM:       11388 B        64 KB     17.38%
        IDT_LIST:         132 B         2 KB      6.45%
[118/118] Linking C executable zephyr/zephyr.elf


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja flash
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Flashing nrf52_pca10040
command: flash


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debug
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debug


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debugserver
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debugserver


Thanks,
Marti


On Wed, May 2, 2018 at 11:39 AM, Armando Visconti <armando.visconti@...> wrote:
Hi,

I added the support for a new stm32-based board, called ArgonKey.

I would like to add the possibility to flash my board using stm32flash
tool using 'make flash', but I noticed that there is no common support
for it. There are many tools already supported, like dfu-util and
jlink.

I'm currently studying the related infrastructure based on a series of
phyton scrips like zephyr_flash_debug.py.

As I'm quite new on zephyr can someone possibly point me to some
documentation on this part?

Thx,
Armando






Re: Add stm32flash to zephyr_flash_debug.py script

Marti Bolivar
 

Hi Armando,

I had written a post about this to the list, but it seems like it is no longer part of the archives since we moved to groups.io (which is unfortunate, I assumed that archives would be preserved).

I reproduce it here for your reference, hope it helps:

You can specify a flash and debug runner without touching any board files by setting BOARD_FLASH_RUNNER and/or BOARD_DEBUG_RUNNER in the CMake command line when generating a build system.

Here is an example branch, in which I have created a "dummy" runner:


Here is the commit which adds the extra runner, which just prints the command instead of acting on hardware:


Here is an example shell session where the flash and debug runners are set at CMake time and then used later using "ninja flash", "ninja debug", and "ninja debugserver". I have used the nrf52_pca10040 board, but it should work with any board.

plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ cmake -GNinja -DBOARD=nrf52_pca10040 -DBOARD_FLASH_RUNNER=dummy -DBOARD_DEBUG_RUNNER=dummy ..
CMake Deprecation Warning at /home/mbolivar/src/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:2 (include)


-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4") 
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.11.99
[snip]
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mbolivar/src/zephyr/samples/hello_world/build


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja
[1/118] Generating always_rebuild
Building for board nrf52_pca10040
[113/118] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       44732 B       512 KB      8.53%
            SRAM:       11388 B        64 KB     17.38%
        IDT_LIST:         132 B         2 KB      6.45%
[118/118] Linking C executable zephyr/zephyr.elf


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja flash
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Flashing nrf52_pca10040
command: flash


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debug
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debug


plop: ~/src/zephyr/samples/hello_world/build (set-runner) mbolivar
$ ninja debugserver
[1/89] Generating always_rebuild
Building for board nrf52_pca10040
[1/2] Debugging nrf52_pca10040
command: debugserver


Thanks,
Marti


On Wed, May 2, 2018 at 11:39 AM, Armando Visconti <armando.visconti@...> wrote:
Hi,

I added the support for a new stm32-based board, called ArgonKey.

I would like to add the possibility to flash my board using stm32flash
tool using 'make flash', but I noticed that there is no common support
for it. There are many tools already supported, like dfu-util and
jlink.

I'm currently studying the related infrastructure based on a series of
phyton scrips like zephyr_flash_debug.py.

As I'm quite new on zephyr can someone possibly point me to some
documentation on this part?

Thx,
Armando





Add stm32flash to zephyr_flash_debug.py script

Armando Visconti
 

Hi,

I added the support for a new stm32-based board, called ArgonKey.

I would like to add the possibility to flash my board using stm32flash
tool using 'make flash', but I noticed that there is no common support
for it. There are many tools already supported, like dfu-util and
jlink.

I'm currently studying the related infrastructure based on a series of
phyton scrips like zephyr_flash_debug.py.

As I'm quite new on zephyr can someone possibly point me to some
documentation on this part?

Thx,
Armando


Re: [ #BluetoothMesh ] possible Bug .. without assigning subscription address to Model, it is reacting to subscription address assign to other Model #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,
It was bug from my side & I've resolved it.
Now everything is working as expected.

Excuse me for that !!

On Wed, May 2, 2018 at 2:31 PM, Vikrant More <vikrant8051@...> wrote:
Hi,

I gone through my code once again & found that it was small bug from my side.
I had forgotten to add "break" in my customized version of $zephyr/samples/bluetooth/mesh .

Extremely sorry for that.

//------------------------------------------------------------------------doer.c----------------------------------------------------------------------------------------------------------------------

#include "common.h"

int8_t  gen_onoff_srv_state, last_gen_onoff_srv_state;
int16_t gen_level_srv_state, last_gen_level_srv_state;

void doer(struct bt_mesh_model *model, struct bt_mesh_msg_ctx *ctx, struct net_buf_simple *buf, uint16_t opcode)
{
    int err=0;

    int8_t tmp8;
   
    int16_t tmp16;

    struct net_buf_simple *msg;

    switch(opcode)
    {

        case 0x8201:    //GEN_ONOFF_SRV_GET

            msg = NET_BUF_SIMPLE(2 + 1 + 4);

            bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x04));

            net_buf_simple_add_u8(msg, gen_onoff_srv_state);

            if (bt_mesh_model_send(model, ctx, msg, NULL, NULL))
            {
                printk("Unable to send GEN_ONOFF_SRV Status response\n\r");
            }
       
           break;


        case 0x8203:    //GEN_ONOFF_SRV_UNACK

            msg = model->pub->msg;

            gen_onoff_srv_state = (unsigned char)global_state;

            if(last_gen_onoff_srv_state != gen_onoff_srv_state )
            {
                last_gen_onoff_srv_state = gen_onoff_srv_state;

                if(gen_onoff_srv_state != 0)
                {
                    NRF_P0->OUT &= ~(1<<13);    //LED ON
                }
                else
                {
                    NRF_P0->OUT |=  (1<<13);    //LED OFF   
                }

                if(model->pub->addr != BT_MESH_ADDR_UNASSIGNED)
                {

                    bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x04));
                    net_buf_simple_add_u8(msg, gen_onoff_srv_state);

                    err = bt_mesh_model_publish(model);

                    if(err)
                    {
                        printk("bt_mesh_model_publish err %d", err);
                    }

                }
            }

            break;

        case 0x8204:    //GEN_ONOFF_SRV_STATUS

            tmp8 = net_buf_simple_pull_u8(buf);

            NRF_P0->OUT ^= (1<<16);

            printk("Acknownledgement from GEN_ONOFF_SRV = %u\n\r",tmp8);

            break;

        case 0x8205:    //GEN_LEVEL_SRV_GET
           
            msg = NET_BUF_SIMPLE(10);

            bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x08));

            net_buf_simple_add_le16(msg, gen_level_srv_state);

            if(bt_mesh_model_send(model, ctx, msg, NULL, NULL))
            {
                printk("Unable to send GEN_LEVEL_SRV Status response\n\r");
            }

            break;

        case 0x8207:    //GEN_LEVEL_SRV_UNACK

            msg = model->pub->msg;

            gen_level_srv_state = (int16_t)global_state;

            if(last_gen_level_srv_state != gen_level_srv_state )
            {
                last_gen_level_srv_state = gen_level_srv_state;

                printk("gen_level_srv_state = %d \n\r" , gen_level_srv_state );
               
                if(gen_level_srv_state > 10000)
                {   
                    CLRB(NRF_P0->OUT,15);
                    SETB(NRF_P0->OUT,16);
                }
                else
                {   
                    CLRB(NRF_P0->OUT,16);
                    SETB(NRF_P0->OUT,15);
                }
                               
                if(model->pub->addr != BT_MESH_ADDR_UNASSIGNED)
                {

                    bt_mesh_model_msg_init(msg,BT_MESH_MODEL_OP_2(0x82, 0x08));

                    net_buf_simple_add_le16(msg,gen_level_srv_state);

                    err = bt_mesh_model_publish(model);

                    if (err)
                    {
                        printk("bt_mesh_model_publish err %d", err);
                    }

                }
            }       
   
            break;

        case 0x8208:    //GEN_LEVEL_SRV_STATUS

            tmp16 = net_buf_simple_pull_le16(buf);
            printk("Acknownledgement from GEN_LEVEL_SRV = %d\n\r",tmp16);

            break;

        case 0x820A:    //GEN_DELTA_SRV_UNACK
           
            break;

        case 0x820C:    //GEN_MOVE_SRV_UNACK
           
            break;

        default:

           break;
    }
}



On Wed, Apr 25, 2018 at 9:28 PM, Vikrant More <vikrant8051@...> wrote:
Hi Kai,

Please see attached mesh.zip file for what you had asked. (Refer DEVICE_composition.c for 
static struct bt_mesh_model root_models[] = {};
             static struct bt_mesh_elem elements[] = { }; )

I have break provided #ZephyrBluetoothMesh sample code into multiple files for simplicity.

Have you faced same issue ?

Please let me Know, if there is bug from my side & keep me in loop if you are going to ask further queries based on it.

Thank You !!

On Wed, Apr 25, 2018, 8:39 PM Vikrant More <vikrant8051@...> wrote:
Hi Kai,
Sorry, today I was busy & didn't get time to access my email. Right now I am on the way to my Home. Tomorrow I will definitely share what you have asked.

Thanks !!

On Wed, Apr 25, 2018, 9:21 AM Kai Ren <kren@...> wrote:
Hi vikrant8051,
Could you please share the following definitions?
             static struct bt_mesh_model root_models[] = {};
             static struct bt_mesh_elem elements[] = { };

Thanks!

Kai




Re: [Zephyr-users] [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi to all,

cd $(zephyr_base)
git fetch origin pull/7283/head:BlueZMeshctl
git checkout BlueZMeshctl 

I execute above commands & re-build samples/bluetooth/mesh & try to provision 
it using BlueZ 5.49 #meshctl. And this time, whole process has completed.

Thank You !!



On Tue, May 1, 2018 at 11:01 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
> > That's a good catch. I'm sorry for not realizing it earlier. I've
> > uploaded an untested pull request that attempts to fix this. Could
> > you
> > try it please:
> >
> >     https://github.com/zephyrproject-rtos/zephyr/pull/7283
>
> Works for me.
>
> Provisioning completes on samples/bluetooth/mesh and connects for
> configuration. The identity connection had previously failed.

Thanks for testing. Could you also please add some sort of "tested to be
working" comment in the PR to help it get merged?

> It's curious that the SILabs provisioner reportedly worked.

It'd indeed be interesting for someone to analyze the difference. E.g.
perhaps it doesn't disconnect the link in between, or maybe it connects
to Network ID advertising (however shouldn't meshctl work then as
well?).

Johan


Re: Azure IOT Device Client SDK

Matthias Boesl
 

Hi David, 

Do you have some PR or branch to look at? since I'm also playing around with Matt and Google JWT here..

Best Regards,

Matthias


On Tue, May 1, 2018, 17:26 David Brown <david.brown@...> wrote:

What I’d like to have is a framework that makes it fairly easy for an app to setup MQTT (possibly HTTPS/REST). The app would be responsible for getting its data, and making calls to a publish function to have them sent upstream.

 

The main difference between AWS, Google, and Azure’s IoT services is how client authentication works. Ideally, this will be pluggable so the client will be similar in each case.

 

David

 

From: <devel@...> on behalf of Tameezuddin Mohammad <mtameezuddin@...>
Date: Tuesday, May 1, 2018 at 6:47 AM
To: <devel@...>
Subject: Re: [Zephyr-devel] Azure IOT Device Client SDK

 

Initially I want to connect to IOT Hub using MQTT and/or HTTPS. My plan is to support all industrial protocols but initial support should be minimum ( CAN, J1939, Modbus, OPC-UA, OBDII, ) and reading some sensor data as well. 

Many Thanks,
Tameez.


Re: [Zephyr-users] [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could
you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283
Works for me.

Provisioning completes on samples/bluetooth/mesh and connects for
configuration. The identity connection had previously failed.
Thanks for testing. Could you also please add some sort of "tested to be
working" comment in the PR to help it get merged?

It's curious that the SILabs provisioner reportedly worked.
It'd indeed be interesting for someone to analyze the difference. E.g.
perhaps it doesn't disconnect the link in between, or maybe it connects
to Network ID advertising (however shouldn't meshctl work then as
well?).

Johan


Re: [Zephyr-users] [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi Johan,

On Tue, 2018-05-01 at 16:37 +0100, Johan Hedberg wrote:
Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
It doesn't appear that bt_mesh_proxy_identity_enable() gets called
in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes
the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey:
7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce:
3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey:
b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005,
addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534
type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags
0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB()
added just before bt_mesh_proxy_identity_enable() >>>>>>
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could
you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283

Thanks.

Johan
Works for me.

Provisioning completes on samples/bluetooth/mesh and connects for
configuration. The identity connection had previously failed.

It's curious that the SILabs provisioner reportedly worked.

Steve


Re: [Zephyr-users] [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283

Thanks.

Johan


Re: Azure IOT Device Client SDK

David Brown
 

What I’d like to have is a framework that makes it fairly easy for an app to setup MQTT (possibly HTTPS/REST). The app would be responsible for getting its data, and making calls to a publish function to have them sent upstream.

 

The main difference between AWS, Google, and Azure’s IoT services is how client authentication works. Ideally, this will be pluggable so the client will be similar in each case.

 

David

 

From: <devel@...> on behalf of Tameezuddin Mohammad <mtameezuddin@...>
Date: Tuesday, May 1, 2018 at 6:47 AM
To: <devel@...>
Subject: Re: [Zephyr-devel] Azure IOT Device Client SDK

 

Initially I want to connect to IOT Hub using MQTT and/or HTTPS. My plan is to support all industrial protocols but initial support should be minimum ( CAN, J1939, Modbus, OPC-UA, OBDII, ) and reading some sensor data as well. 

Many Thanks,
Tameez.


Re: Azure IOT Device Client SDK

Tameezuddin Mohammad
 

Initially I want to connect to IOT Hub using MQTT and/or HTTPS. My plan is to support all industrial protocols but initial support should be minimum ( CAN, J1939, Modbus, OPC-UA, OBDII, ) and reading some sensor data as well. 

Many Thanks,
Tameez.


Re: [Zephyr-users] [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi,

I had a chance to look at this further.

More at the bottom.


On Thu, 2018-04-26 at 15:24 +0300, Johan Hedberg wrote:
Hi,

This was already identified as a bug in meshctl by Steve, a week ago
or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr
project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of
today, you can see that my log is the same like yours, after close
the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb

Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX: 03 00 10

GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00

Got provisioning data (12 bytes)

01 04 00 01 00 00 06 00 18 00 00 00

GATT-TX: 03 02 00 00 02 04 06

GATT-TX: 03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is
basing on the commit, c33087d3366f395168d477feb631aae1785a008e on
March 29th, it works well, you can see below screenshot that BlueZ
could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 03 00 10
GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00
Got provisioning data (12 bytes)
01 04 00 01 00 00 06 00 18 00 00 00
GATT-TX: 03 02 00 00 02 04 06
GATT-TX: 03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-
00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002add-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002ade-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys,
just guessing…

Regards,
Kai



From: Vikrant More <@vikrant8051>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <
devel@...>, "users@..." <us
ers@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh
provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh
library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did
not complete.

This is complete log,
-----------------------------------------------------------------
-----------------------------------------------------------------
-----------------------------------------------------------------
-------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...
m<mailto:@vikrant8051>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...<mailto:kr
en@...>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make
model configuration, use meshctl "menu onoff" to control LED on and
off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last
week, it was successful, so BlueZ works well, the issue may be from
Zephyr.

Kai

It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>

Steve


Re: Azure IOT Device Client SDK

David Brown
 

I’m not aware of any work on Azure. I am putting some work into having better support for Google Cloud services, and I intend the result to be fairly easy to adapt to other providers. Do you know your requirements? Connection to the cloud, with publish, possibly subscribe, and something meaningful with config updates?

 

Thanks,

David

 

From: <devel@...> on behalf of Tameezuddin Mohammad <mtameezuddin@...>
Date: Monday, April 30, 2018 at 4:15 AM
To: <devel@...>
Subject: [Zephyr-devel] Azure IOT Device Client SDK

 

Hi there,
Want to know if someone is working on the Azure IOT Device SDK ( Client )  to port to Zephyr, Is Microsoft have some plans to support Zephyr RTOS via device SDK?

Regards,
Tameez Mohammad


Re: Extending Error Codes

piotr.ziecik@...
 

Hi.

I do not think that per-module error codes are good idea.

First, you cannot to this:
foo_error_t foo(void)
{
boo_error_t error = boo();
if (error != BOO_SUCCESS)
return error; // Here you are changing the meaning of the message. If the error will be propagated further the correct meaning will dissolve and the error code will become useless.
}

To solve the problem shown above you will need a translation:
foo_error_t foo(void)
{
boo_error_t error = boo();

// Waste of space here: copy-paste to each function using BOO and hard to maintain:
switch (error) {
case BOO_SUCCESS:
return FOO_SUCCESS;

case BOO_NOT_FOUND:
return FOO_NOT_FOUND;

default:
// Please maintain me 😊
__ASSERT(false);
}
}

IMHO the best solution is to extend the errno.h, but please remember that all errors defined there must be generic (reusable across different modules).

Best Regards,
Piotr Zięcik
Senior Firmware Engineer
M: +48 698 726 973



Nordic Semiconductor Poland sp. z o.o.
ul.Bratyslawska 1A, 31-201 Krakow, Poland
www.nordicsemi.com

-----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of Puzdrowski, Andrzej
Sent: Monday, April 30, 2018 3:53 PM
To: devel@...
Subject: Re: [Zephyr-devel] Extending Error Codes

I also see that error cods defined in <errno.h> are insufficient.
I think definition value-space for module specific codes are good idea in general. But I'm afraid we can go down the road in case we relaxed the line.
Also we can consider addition of generic codes to existing definitions (which is better idea).

Andrzej

-----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of laczenJMS
Sent: Friday, April 27, 2018 5:32 PM
To: devel@...
Subject: [Zephyr-devel] Extending Error Codes

Hello Zephyr Developers,

I recently had a request to change the error codes in a zephyr module to use the standard supplied error codes. Doing so would reduce the descriptiveness of the error codes so I did not really like this.
However in my module I was using error codes (-) 1 to 10, and I think this was a bad idea. If someone needs to check the error code he/she might end up looking at errno.h and finding a completely different definition.

Would it not be a good idea to allow extending the standard error codes with module (subsystem) specific error codes that can be as descriptive as required by allowing modules to use error codes above a specific value. E.g. any module can use it's own error codes starting from 0x7F00 to 0x7FFF. This way it is possible to avoid overlap between standard errors and "user" errors.

What's your opinion ?

Kind regards,

Jehudi


Re: Extending Error Codes

Puzdrowski, Andrzej
 

I also see that error cods defined in <errno.h> are insufficient.
I think definition value-space for module specific codes are good idea in general. But I'm afraid we can go down the road in case we relaxed the line.
Also we can consider addition of generic codes to existing definitions (which is better idea).

Andrzej

-----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of laczenJMS
Sent: Friday, April 27, 2018 5:32 PM
To: devel@...
Subject: [Zephyr-devel] Extending Error Codes

Hello Zephyr Developers,

I recently had a request to change the error codes in a zephyr module to use the standard supplied error codes. Doing so would reduce the descriptiveness of the error codes so I did not really like this.
However in my module I was using error codes (-) 1 to 10, and I think this was a bad idea. If someone needs to check the error code he/she might end up looking at errno.h and finding a completely different definition.

Would it not be a good idea to allow extending the standard error codes with module (subsystem) specific error codes that can be as descriptive as required by allowing modules to use error codes above a specific value. E.g. any module can use it's own error codes starting from 0x7F00 to 0x7FFF. This way it is possible to avoid overlap between standard errors and "user" errors.

What's your opinion ?

Kind regards,

Jehudi