I am able to register a device on Cumulocity IoT and send measurements from the device to Cumuloicty via MQTT. Now I want to send measurement from Cumulocity to that registered device using MQTT. How can I achieve this ?
I tried going through all the documents available on cumulocity but its not mentioned clearly in those docs how we can achieve this flow. I tried the control tab in device which lets us send some single and bulk operations but did not get to a solution.
All communication from Cumulocity IoT to devices is technically covered through operations. Even if maybe in your case the content of the operation is a measurement value, set point or something like this.
The structure of the operation doesn't matter for Cumulocity IoT. Your device in the end needs to understand it.
If you have for example a case where device A sends a measurement (to Cumulocity IoT) and you want device B to receive this measurement you will need to create an operation for device B out of the measurement of device A.
This can be quite easily achieved utilizing the built-in streaming analytics in Cumulocity IoT (see https://cumulocity.com/guides/apama/overview-analytics/). Fastest approach would be the Analytics Builder.
Related
I am currently doing a POC where I would like to know if this is possible using Azure Services. I get certain data from Iot hub in my Event hub which triggers a logic app, and based on the message received from Event hub, My logic app would send a message to IoT Edge device. i would like to know if it is possible to send message to IoT hub device from logic app? and if yes how can we do that?
I am more looking Yes or No answer to my question and If I get the services to be used to achieve this.. It will be great
Yes, this is possible. Logic Apps have an Event Hub connector that you can use to start your app when a message comes in.
To send a message to your Azure IoT Edge device from a logic app, you could use the REST API. It allows you to send a direct method to a specific module on the device. The device needs to be online for it to receive the message, otherwise, the REST call will result in an error.
The challenge is that you will need to get a valid security token to complete this call, you could certainly add this to your app as a variable, but you shouldn't. You also run the risk of exposing this secret value in your run history. You could write an Azure Function to generate this security token and retrieve it with the Logic App. At this point you're writing code anyway, the problem you're trying to solve with a Logic App would be a better fit for an Azure Function.
I work for a company that manufactures large scientific instruments, with a single instrument having 100+ components: pumps, temperature sensors, valves, switches and so on. I write the WPF desktop software that customers use to control their instrument, which is connected to the PC via a serial or TCP connection. The concept is the same though - to change a pump's speed for example, I would send a "command" to the instrument, where an FPGA and custom firmware would take care of handling that command. The desktop software also needs to display dozens of "readback" values (temperatures, pressures, valve states, etc.), and are again retrieved by issuing a "command" to request a particular readback value from the instrument.
We're considering implementing some kind of telemetry service, whereby the desktop application will record maybe a couple of dozen readback values, each having its own interval - weekly, daily, hourly, per minute or per second.
Now, I could write my own telemetry solution, whereby I record the data locally to disk then upload to a server (say) once a week, but I've been wondering if I could utilise Azure IoT for collecting the data instead. After wading through the documentation and concepts I'm still none the wiser! I get the feeling it is designed for "physical" IoT devices that are directly connected to the internet, rather than data being sent from a desktop application?
Assuming this is feasible, I'd be grateful for any pointers to the relevant areas of Azure IoT. Also, how would I map a single instrument and all its components (valves, pumps, etc) to an Azure IoT "device"? I'm assuming each component would be a device, in which case is it possible to group multiple devices together to represent one customer instrument?
Finally, how is the collected data reported on? Is there something built-in to Azure, or is it essentially a glorified database that would require bespoke software to analyse the recorded data?
Azure IoT would give you:
Device SDKs for connecting (MQTT or AMQP), sending telemetry, receiving commands, receiving messages, reporting properties, and receiving property update requests.
An HA/DR service (IoT Hub) for managing devices and their authentication, configuring telemetry routes (where to route the incoming messages).
Service SDKs for managing devices, sending commands, requesting property updates, and sending messages.
If it matches your solution, you could also make use of the Device Provisioning Service, where devices connect and are assigned an IoT hub. This would make sense, for instance, if you have devices around the world and wish to have them connect to the closest IoT hub you have deployed.
Those are the building blocks. You'd integrate the device SDK into your WPF app. It doesn't have to be a physical device, but the fact it has access to sensor data makes it behave like one and that seems like a good fit. Then you'd build a service app using the Service SDKs to manage the fleet of WPF apps (that represent an instrument with components, right?). For monitoring telemetry, it would depend on how you choose to route it. By default, it goes to an EventHub instance created for you. You'd use the EventHub SDK to subscribe to those messages. Alternatively, or in addition to, those telemetry messages could be routed to Azure Storage where you could perform historical analysis. There are other routing options.
Does that help?
I am working on BLE application on a embedded platform where there are frequent connect/disconnect events. The issue I am seeing is re-connection takes too long. The high frequency of connect/disconnect is a part of usage scenario so I can't change that. What I can do is make the re connection more efficient. I noticed, the bulk of re-connection is spent of service/characteristic discovery of other devices.
I still want to make sure the service/characteristic of the connecting device hasn't been changed. In stead of discovering all the service , can we instead use a characteristic that has the hash of all the service/characteristic on the device? So each device can compare the received hash with the stored one. Only in case of mismatch perform full service discovery. Is there a precedent of doing it in BLE?
Bluetooth Low Energy (BLE) allows devices to leave their transmitters off most of the time to achieve its “Low Energy”.
I would expect a central device to subscribe to notifications from the peripheral. That way the peripheral only turns on and transmits when there are updates.
The other approach would be to put the data (or hash) in the advertising data (manufacturer data or service data) like many sensor beacons do. That way you might not need to connect at all or only connect if needed.
I'm trying to wrap my head around how to subscribe to events in the new Sonos API for an iOS app.
It seems like a cloud service is needed to receive events from the Sonos Cloud.
As described here:
[Subscribing to events with Sonos API
[https://developer.sonos.com/build/direct-control/connect]
Is there any way for an iOS app to subscribe to events (volume and grouping change) without having to run a cloud service?
If not, any features based on event subscriptions will not be able to work if there is trouble connecting to the cloud for whatever reason.
No, there's no way to run without a cloud service. You must have a reliable cloud service for events and subscriptions.
Each device also has a super fast / local / undocumented, UPNP service that also supports events.
this answer should give you some pointers on how to get it working in node.
In a nutshell:
Setup an http endpoint on the device (not sure how that works in Swift)
Tell (in node) the speaker to start sending events for a specific service
Handle the received XML events.
Sample event from RenderingControlService (yes it has nested encoded xml in the <LastChange> property):
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"><e:property><LastChange><Event xmlns="urn:schemas-upnp-org:metadata-1-0/RCS/"><InstanceID val="0"><Volume channel="Master" val="15"/><Volume channel="LF" val="100"/><Volume channel="RF" val="100"/><Mute channel="Master" val="0"/><Mute channel="LF" val="0"/><Mute channel="RF" val="0"/><Bass val="0"/><Treble val="0"/><Loudness channel="Master" val="1"/><OutputFixed val="0"/><HeadphoneConnected val="0"/><SpeakerSize val="3"/><SubGain val="0"/><SubCrossover val="0"/><SubPolarity val="0"/><SubEnabled val="1"/><SonarEnabled val="1"/><SonarCalibrationAvailable val="1"/><PresetNameList val="FactoryDefaults"/></InstanceID></Event></LastChange></e:property></e:propertyset>
We have around 9000 devices in field.
This devices are at groups of 1-100 at customers on prem.
The devices are not capable of azure-iot-sdk integration.
The devices have a webservice API.
The devices should appear as first-class devices in azure.
We like the iot edge module provisiong feature.
We want to evaluate if modules could gather data from the devices and send them to IoTHub for further processing.
We found this feature overview of IoTEdge: https://learn.microsoft.com/de-de/azure/iot-edge/iot-edge-as-gateway
Pattern Transparent and Protocol translation are out of scope due to above facts. Pattern Identity translation seems to fit.
We want a 1 to 1 relationship between module and real device.
Therefor we assume the following POC with the hope of clarification and best practise:
we implement a iot edge module (azure-iot-sdk-java)
we open module connection to iotedge and suscribe to desired properties
the module identity gets as desired property the ip of the real device and the azure device identitiy connection string.
we open device connection to iotedge by adding GatewayHostName to the device connection string as described here https://learn.microsoft.com/de-de/azure/iot-edge/iot-edge-as-gateway
we request data from the real device and send them via azure device identity.
This somewho mixes up two patterns and seems kind of odd to us.
Can you point out best practises and risks with this approach?
Yes, I agree with that Pattern Identity translation could fit your scenario.
There are three patterns for using an IoT Edge device as a gateway: transparent, protocol translation, and identity translation, you can refer to this link to get more introduction about these three pattern.