Is it possible to set IoT Explorer telemmetry interval to less than 1 second so we can update device twin and digital twins in milliseconds? We are working with mxchip AZ3166 device.
I've raised feature request.
Adding answer from GitHub for the community benefit.
This is not a common request, and we suggest following the instructions below and build your own app:
Run the app locally or event build it yourself
https://github.com/Azure/azure-iot-explorer#run-it-locally-and-build-it-yourself
Change line 39's LOADING_LOCK from 8000 to below 1000 (1000 ms which is 1 second) to suit your use case
https://github.com/Azure/azure-iot-explorer/blob/main/src/app/devices/deviceEvents/components/deviceEvents.tsx#L39
Related
I recently started a project with Azure IoT Edge with the IoT Hub Free Tier so I'm a total beginner. I set up a device sensor, a module and I am sucessfully sending data to my module and IoT Hub. I can
monitor the messages sent from the sensor with Azure IoT Hub expension from Visual Studio Code.
I can see the messages I'm sending but I am having an issue with the number of messages being sent.
I use Azure portal metrics to monitor the number of messages sent and very often Azure would show me different numbers as I refresh. For example "1000" messages and after a refresh "800" messages etc...
Another issue I'm having is also that when using the Metrics functionality, it shows me that some messages are being sent during a time where my sensors weren't sending any messages.
Is there a way to get a detailled report with a history on the messages that the Hub receives?
Any help or advice would be highly appreciated! Thank you
As far as I know there is no "nice and simple" report which will show you what you need. However, if you want to get historical events which IoT hub processed it can be done. Note, though, that history is limited and can be no longer than 7 days. Current retention period can be seen on the azure portal in "Built-in endpoints" section - there is a "Retain for" setting with the value from 1 day (default) to 7 days.
If events are within this range, you can use Powershell command "az iot hub monitor-events" with the --enqueued-time parameter to "look back" in history. The time is specified in milliseconds since unix epoch. Example command:
az iot hub monitor-events --hub-name 'your_iot_hub_name' --device-id 'your_registered_device_id' --properties all --enqueued-time 1593734400000
I'm developing a web application in .NET Core 3 and I'm using the Microsoft.Azure.Devices.RegistryManager to access an Azure Iot hub.
When I call registryManager.UpdateTwinAsync(), I have to send in the "etag". And sometimes the etag changes and I get errors stating that there is an etag mismatch.
I basically don't understand what the etag's purpose is and how I can update device twins in a safe manner. Anyone?
I tried catching those exceptions and fetching the etag from the device twin and retrying up to 15 times in a row with 2 seconds wait in between and that helps, but this error pops up every now and then. I would think that applying the device id would be enough to update a device twin but apparently not
Please help!
So in a simple terms we can say that ETag - Entity tag will keep changing when ever we see there is a change in device status or any other updates.
A string representing a weak ETag for the device identity, as per RFC7232 Section 2.3 Etag.
An entity-tag is an opaque validator for
differentiating between multiple representations of the same
resource, regardless of whether those multiple representations are
due to resource state changes over time
For example: Enable and Disable an IoT Device and check the 'Get device Info' from Visual Studio Code (Azure IoT Hub Extension)
Step 1) I have an initial IoT device with status Enabled and I can see an Etag value.
Step 2) When I disabled the device on IoT Hub portal, and then did second query 'Get Device Info' call, I see a different value on ETag.
Step 3) Now when I queried for the second time (like after 5 mins interval), I see the Etag value remains same for the same disabled state of device.
**For more info please visit Device identity properties, Module identity properties
**Please let us know if you need more help on this!
My understanding is that the ETag is used to ensure consistency on the device twin when you're updating it. It's read-only so you would get it from your device twin and pass it back to UpdateTwinAsync() with your changes. Link
I'm not sure what you mean when you say the ETag is changing - can you provide some code of what you are doing (or clarify when the ETag is changing)?
I created a video on YouTube that demos how to read/write Azure Device Twins, so feel free to check it out, hopefully it helps you! Link
For some additional information about how device twins use optimistic concurrency to ensure consistency when there are potentially multiple updates from different users, see Understand and use device twins in IoT Hub > Optimistic concurrency on Microsoft Docs.
I have a free tier subscription to Azure IoT hub with only two edge devices connected to it, one of them mostly off. Yesterday, it looks like my hub recorded a slew of messages--within 45 minutes (5 to 5:45 pm PST), 25K messages were recorded by the hub. A few related issues.
I'm not sure what these messages were. I'll add message storage for the future, but wondering if there's a way to debug this.
Ever since then, I haven't been able to use the IoT hub. I get a "message count exceeded" error. That made sense till around 5 pm PST today (same day UTC), but not sure why it is still blockign me after that.
I tried to change my F1 to a basic tier to basic, but that wasn't allowed because I am apparently "not allowed to downgrade"
Any help with any of these?
1.I'm not sure what these messages were. I'll add message storage for the future, but wondering if there's a way to debug this.
IoT Hub operations monitoring enables you to monitor the status of operations on your IoT hub in real time. You can use it to monitor Device identity operations,Device telemetry,Cloud-to-device messages,Connections,File uploads and Message routing.
2.Ever since then, I haven't been able to use the IoT hub. I get a "message count exceeded" error. That made sense till around 5 pm PST
today (same day UTC), but not sure why it is still blockign me after
that.
IoT Hub Free edition enables you to transmit up to a total of 8,000 messages per day, and register up to 500 device identities. The device identity limit is only present for the Free Edition.
3.I tried to change my F1 to a basic tier to basic, but that wasn't allowed because I am apparently "not allowed to downgrade".
You cannot switch from Free to one of the paid editions. The free edition is meant to test out proof-of-concept solutions only.
Confirming the earlier answer, the only solution is to delete the old hub and create a new free one, which is simple enough.
I still haven't figured out what those specific error messages were, but I do notice that when there are errors such as CA certificate auth failures, lots of messages get sent up. I'm still working with MSFT support on the CA certificate signing issues, but this one is a side effect.
For future reference, look at yoru hub's metrics, and note that (i) quote gets reset midnight UTC, but (ii) net violations do not.
HelloA Windows Phone application need to connect to a server and get messages from it. This is done using WCF and long polling on the server. 3 minutes is the timeout defined on the server. Call from windows phone is done using HttpWebRequest.
The problem is that Windows Phone devices have a timeout of 60 seconds for get request (emulator have a different value, greater than 3 minutes).
Currently i can't decrease server timeout. Doing a new GetRequest after the 60 seconds doesn't get anymore messages.
Does anyone have an idea ?
Thanks
I don't think leaving a connection open is a good idea on mobile devices. I'm assuming that's what you're doing. In my app, I would just poll whenever needed by creating a new HttpWebRequest. But it made sense to do this in my app, because I would be updating train arrival status every 40 seconds.
If you're trying to pull data on a given schedule, put a timer in and just call the webserver every 3 minutes or whatever the requirement is.
If you want to be able to check things (when the app is closed) or if there's rarely fresh data on the server, then you'd need to implement a Push mechanism.
Update: Here's a good article on dealing with the timeout issue - http://blog.xyzzer.me/2011/03/10/real-time-client-server-communication-on-windows-phone-with-long-polling/
Update 2: What if you arranged it so that, you have cascading connections - what I mean is since you can't go beyond 60 seconds per connection, you can write a class that'll house two connections and once one of them is about to timeout, say several seconds before, you can start opening the other connection - you can pick the timing so that there's at most 5 seconds of overlap between them. This way you could have your always open connection.
Also see what these guys have done with the GChat app, they have their source code available at this link. This may provide a more proper design.
I am using MSP430F5418 wit IAR EW 5.10.
In my project I am using FreeRTOS 7.0 as operating system.
Consider the scenerio:
Setup RTC in alarm mode with one minute interrupt.
Create two tasks.
When one minute interrupt arrives, send a request to task 2 by task 1.
Task 2 response to to task 1 with 4 messages.
While receiving messages task 1 calls a simple function which loops for 0x7FFF times.
Here, after the 4th request, an RTC interrupt is generated immediatly even if one minute is not passed.
I am using the Work-around code provided by TI for RTC manipulation.
Can anybody please tell me why this unexpected behaviour happens???
Thank you,
Hari
I would say that you have two options
Use the newer F5418A which has the RTC problems fixed.
Don't use the RTC
I have a project based on the 5418 that was ported from an F149, which does not have a hardware RTC. As part of the porting process use of the software RTC was replaced with the hardware module. The TI code was used but there were so many problems with the registers not writing properly that the software RTC was put back in.