|
Re: Azure IOT Device Client SDK
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@...>
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.
|
|
|
|
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,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
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@...>
Hi there,
|
|
|
|
Re: Extending Error Codes
piotr.ziecik@...
Hi.
toggle quoted messageShow quoted text
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@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Puzdrowski, Andrzej Sent: Monday, April 30, 2018 3:53 PM To: devel@lists.zephyrproject.org 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@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of laczenJMS Sent: Friday, April 27, 2018 5:32 PM To: devel@lists.zephyrproject.org 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.
toggle quoted messageShow quoted text
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@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of laczenJMS Sent: Friday, April 27, 2018 5:32 PM To: devel@lists.zephyrproject.org 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
|
|
|
|
Azure IOT Device Client SDK
Tameezuddin Mohammad
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: [Zephyr-users] Device Firmware Update + Zephyr +
#bluetoothmesh
Rodrigo Peixoto <rodrigopex@...>
Vikrant, answering inline.
Ok.
I really need that.
Do you need help on that? I am a little bit confusing. I was willing to create the sample related to OTA and mesh. But if there is other sample as you said related to mesh, it would be a pleasure to help. Is there any thing I can do? Best regards, Rodrigo Peixoto.
|
|
|
|
Re: [Zephyr-users] Device Firmware Update + Zephyr +
#bluetoothmesh
vikrant8051 <vikrant8051@...>
Hi Rodrigo, Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. Now I will prefer to wait till 1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash 2) plus it should also take care of saving data like sequence no. & Model states on SoC flash on periodic basis This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective. There will be roughly four section in SoC flash- 1. for MCUboot 2. for flash memory (which will acts like eeprom) 3. slot_0 (current image) 4. slot_1 ( temporary location for new image after DFU ) This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution. Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image. Regards, Vikrant
On Fri, Apr 27, 2018, 7:44 PM Rodrigo Peixoto <rodrigopex@...> wrote:
|
|
|
|
Extending Error Codes
laczenJMS
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: Shave Zephyr boards with Occam's razor
Erwan Gouriou
Good! Thanks Carles.
On 27 April 2018 at 14:53, Cufi, Carles <Carles.Cufi@...> wrote:
|
|
|
|
Re: Shave Zephyr boards with Occam's razor
Carles Cufi
In case anyone is wondering, the current dtc version in our Windows packaging scheme is 1.4.4, so we should be safe in this regard.
From: devel@... <devel@...>
On Behalf Of Erwan Gouriou
Sent: 27 April 2018 14:35 To: Marti Bolivar <marti@...> Cc: Bøe, Sebastian <Sebastian.Boe@...>; zephyr-devel <zephyr-devel@...> Subject: Re: [Zephyr-devel] Shave Zephyr boards with Occam's razor
Hi all, Guidelines for default board configuration are now documented in Zephyr board porting guide. Next step will be to get all existing boards to comply with these guidelines. I've open issue #7191: boards: Move existing boards to "default configuration guidelines"[0] to drive this. PR #7176[1] has also been created to provide a reference for board configuration, comments are welcome. Please note that this activity has a dependency on upcoming SDK v0.9.3, as introduction of connectors in device tree files requires usage of dtc > v1.4.1 [3]. Erwan
On 29 March 2018 at 17:14, Erwan Gouriou <erwan.gouriou@...> wrote:
|
|
|
|
Re: Shave Zephyr boards with Occam's razor
Erwan Gouriou
Hi all, Guidelines for default board configuration are now documented in Zephyr board porting guide. Next step will be to get all existing boards to comply with these guidelines. I've open issue #7191: boards: Move existing boards to "default configuration guidelines"[0] to drive this. PR #7176[1] has also been created to provide a reference for board configuration, comments are welcome. Please note that this activity has a dependency on upcoming SDK v0.9.3, as introduction of connectors in device tree files requires usage of dtc > v1.4.1 [3]. Erwan [0]https://github.com/zephyrproject-rtos/zephyr/issues/7151 [1]https://github.com/zephyrproject-rtos/zephyr/issues/7176 [3]https://github.com/zephyrproject-rtos/meta-zephyr-sdk/issues/92
On 29 March 2018 at 17:14, Erwan Gouriou <erwan.gouriou@...> wrote:
|
|
|
|
Re: [Zephyr-tsc] Examples for "Zstream" Socket/TLS API
Paul Sokolovsky
Hello Patrik,
On Fri, 27 Apr 2018 09:37:23 +0000 "Flykt, Patrik" <patrik.flykt@intel.com> wrote: Hi,The "big_http_download" example I was talking about is based on the "http_get" and is a further extension of it. Unlike "http_get", which makes an HTTP(S) request for a couple KBs of data, "big_http_download" makes a request for a multi-megabyte file, and checks the integrity of received data (that it matches a known hash). That's the difference.
-- Best Regards, 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: [Zephyr-tsc] Examples for "Zstream" Socket/TLS API
Flykt, Patrik <patrik.flykt@...>
Hi,
On Thu, 2018-04-26 at 22:43 +0300, Paul Sokolovsky wrote: I would like to propose to Patrik, the author of the alternativeI looked through the socket based samples in the Zephyr source code and for the sake of presenting the various API options, I think we should go with something very close to the http_get/ example code. This in order to have a clear and easy presentation of the various options available. I'll simplify that code a bit and distribute it to you and Jukka in another email thread, so that we can have the same example done with different APIs and presented in the Networking Forum. Regards, Patrik
|
|
|
|
Examples for "Zstream" Socket/TLS API
Paul Sokolovsky
Hello,
At yesterday's TSC meeting, it was requested to provide examples of the usage of 2 contender TLS APIs, to better assess trade-offs they make. (Please see an earlier email today re: background on TLS API situation). Here's an information about usage examples for my Zstream API (https://github.com/zephyrproject-rtos/zephyr/pull/5985). Work on examples was the integral part of my PR. Currently, Zephyr has 5 samples for BSD Socket usage in the tree: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets While developing my API, I converted each of them in turn from pure BSD Sockets API to Zstream API. Beyond that, I also added build files (specifically, Makefiles) which allow to build all these samples on another POSIX-compatible OS, tested on Linux. In this regard, the Zstream samples are the same as the original Socket samples they were derived from - they also have the makefiles and demonstrate portability to other systems offering BSD Sockets API. Note that requirement of portability across POSIX OSes was one the basic requirements for the design of Zstream API. Beyond converting the existing socket samples, I also converted a WIP socket-based MQTT client PR, as previously prepared by Gil Pitney: https://github.com/zephyrproject-rtos/zephyr/pull/5854 With the above work done, for the final version of PR in https://github.com/zephyrproject-rtos/zephyr/pull/5985 , I decided to include just one sample, to not overload reviewers, I decided to include just one example, "the most complex" in a sense, "big_http_download", which downloads a large file (few MBs) over HTTPS connection and verifies its hash. Summing up, the following samples are available for review: 1. https://github.com/zephyrproject-rtos/zephyr/pull/5985 includes a *standalone* version of "big_http_download" sample, i.e. all related files are added as new (to keep the socket-based original intact, as of course Zstream API does not replace BSD Socket API, it's optional layer on top of it). Direct link: https://github.com/zephyrproject-rtos/zephyr/pull/5985/files#diff-0bbecb3596925b2de875604e14faa3fd (may be broken if rebase happens). 2. All the samples mentioned above can be viewed in a diff form in my branch: https://github.com/pfalcon/zephyr/tree/net-zstream-api-samples . To ease the review, I created a pseudo-PR which allows to access the diffs directly. For example, the diff between the original socket version of "big_http_download" and its Zstream conversion is here: https://github.com/pfalcon/zephyr/pull/2/files#diff-63c8f742bbf5c8012d95ebf51d4eeef2 I would like to propose to Patrik, the author of the alternative proposal, to take the "big_http_download" socket sample as the baseline for API comparison (followed by the other 4 in-tree samples if there're enough resources). I also would like to draw attention to showing portability of a TLS application to other POSIX/BSD Sockets OSes. 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: FOTA takes so long to complete (MCUBoot + mcumgr + Bluetooth)
Hi,
On Thu, Apr 26, 2018, Luiz Augusto von Dentz wrote: There are a few things that might help:3. Use the 2Mbps Phy. The code should already be setting a preference to it automatically, so I *think* it then only depends on whether the remote side is able to do 2Mbps. Johan
|
|
|
|
Re: FOTA takes so long to complete (MCUBoot + mcumgr + Bluetooth)
Luiz Augusto von Dentz
Hi Rodrigo,
toggle quoted messageShow quoted text
There are a few things that might help: 1. Increate the GATT MTU: We might need to increase the buffer size on Zephyr and then use Exchange MTU command to enable it. By default, it is set to 23 bytes only. 2. Enable L2CAP CoC as transport: That might be the fastest way to do file transfer with BLE but that has to be enabled in mcumgr which I don't think is the case. I tested the speed of a it some time back and I got something around 20KBps using BlueZ's l2test.
On Thu, Apr 26, 2018 at 6:20 PM, Rodrigo Peixoto <rodrigopex@gmail.com> wrote:
Hello, --
Luiz Augusto von Dentz
|
|
|
|
FOTA takes so long to complete (MCUBoot + mcumgr + Bluetooth)
Rodrigo Peixoto <rodrigopex@...>
Hello, I could make the FOTA via Bluetooth work following the documentation (http://docs.zephyrproject.org/samples/subsys/mgmt/mcumgr/smp_svr/README.html). It was not so easy, in fact, some parts of that were tricky to me. Besides that, I could merge it with the mesh_onoff sample. The FOTA portion of the code is working properly, but I still need to check if the mesh is running properly after merging. The only thing I am concerned about is the upload data rate. It takes too long when updating an image with 130KB, it takes in average 2 or 3 minutes (my board: nrf52840 DK). Nowadays, my solution is based on 600 devices, in a near future, it will be 3000. Make some superficial calculations it will take at least 6000 minutes which is 100 hours which is 12.5 work days (8 hours per day) running without stop. God, it is a real pain. Is there anything I can do to speed up that? Any clue on that? Is there any way to make this in parallel via mesh network or something like that? Thank you very much. Best regards, Rodrigo Peixoto Ayna.tech {+55 (82) 98144-8585}
|
|
|
|
[RFC] TLS API(s) for Socket-based applications in Zephyr
Paul Sokolovsky
Hello,
It occurred to me that the matter of TLS API for BSD Sockets based application, which was discussed for few months at the online (spoken) Zephyr Networking Forum meetings and in Github tickets, and recently, at the TSC meetings, was never RFCed to the development list. As recently there was request to send additional information to this list, let me start with some introduction of the matter, so the context was clear. Currently, Zephyr supports TLS networking via its "net_app" API, which is Zephyr-specific and was shown to have some issues with developing some kinds of applications. There's growing interest in adopting BSD Sockets API, as also available in Zephyr, as means to address these issues and increase portability and reusability in general. At the Networking Forum if December 2017, there was a call to develop TLS API suitable for use with Sockets. (Just as net_app makes it possible to use it with net_context native API of Zephyr). I volunteered to design and implement such an API, and started on it soon after NY holidays. The initial discussion happened in https://github.com/zephyrproject-rtos/zephyr/issues/5900 , with incremental implementation work following in https://github.com/zephyrproject-rtos/zephyr/pull/5985 (nicknamed "Zstraam API") . The pull request was targeted for 1.12, as planned LTS release. It is ready for about a month now - technical issues resolved, CI passes. More recently, at the April Networking Forum, there was an alternative proposal from Patrik Flykt, based around an idea of reusing Sockets API directly for TLS communication, effectively pushing TLS under the level of TCP/IP stack. A week-old work-in-progress PR for it is at https://github.com/zephyrproject-rtos/zephyr/pull/7118 , nicknamed "setsockopt-based approach" (note that a lot of discussion of it still happens in #5985). So, the following summarizes the situation: 1. There's one PR, which has been under detailed development for last 3 months, based on the previous agreement of a way to do it - by now ready, but not approved (because of thoughts that an alternative may offer more benefits). 2. There's a new alternative PR, not finished so far, and with some concerns, both paradigmatic and technical, raised. There's a concern that this situation deadlocks addition of TLS Sockets API to 1.12 LTS, that's why this matter was raised for the TSC consideration, who asked to provide specific additional information to compare the 2 approaches. It's supposed to be sent in the following messages. 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
|
|
|