I am quite new to both MQTT and the LOSANT platforms, so please forgive the simplicity of this question:
I am using particle photon and based on the nice GitHub example “Losant/example-particle-mqtt” from spacetc62
I have been able to publish multiple variables and have built a nice dashboard
however when I subscribe to variables, I never get a callback when I change them, either via the dashboard widget or by forcing the value in the debug mode.
MQTT is based around publishing and subscribing to basically any topic you choose. The Losant broker treats the following two topics differently so we can support our concept of device state and commands over MQTT.
losant/:deviceId/state
losant/:deviceId/command
In your Particle firmware, you used the state topic to publish device attributes. You can also subscribe to the topic to be notified whenever the device state changes. If you use the “Force State” feature, for example, this topic will receive a message.
The command topic is used to send your device commands. When using the Input Controls block on a dashboard, you’ve got two options: either invoke a workflow, or send a command. If you chose to send a command, this command topic will receive the message.
You are free to publish and subscribe to any other MQTT topics you choose, but Losant’s built-in state/command features will only ever publish to the above two topics.
Brandon, that helps a lot. However I am still unclear on how I can subscribe to say a range variable, so that whenever it is changed, I get a callback. If I subscribe to states, won’t I get callbacks every time I publish? I didn’t see a simple path to use the workflow to trigger a command based on a change in range value
Also, in a workflow diagram what is the proper way to trigger say an SMS based on the value from a gauge query?
many thanks
David
You are correct, if you subscribe to the state topic, you will receive a callback every time you publish.
The best way to get a callback whenever a value changes is to use a Device trigger, an On Change node, and then a Device Command node.
The Device trigger occurs whenever one of your devices publishes state. You can then use the On Change node, or any other nodes, to determine when you’d like to receive a callback. You then use the Device Command node to send your device the required command.
In terms of sending an SMS, if you want an alert based on the most recent value, I’d stick with using the Device trigger. For example, if you want to get an SMS when the temperature exceeds 90 degrees, you’d use a Device trigger, a Latch node, and the SMS node. The Latch node works a lot like the Conditional node, but will prevent duplicate messages if the device reports over 90 degrees several times in a row.
If you want to get an SMS with the result of a gauge query pulling historical data, for example the average temperature over the last 24 hours, you’ll have to trigger the workflow somehow. You can use a Timer to send it once a day, you can use an Experience Endpoint or a Webhook to do it via an API request, you can use a Virtual Button, or many others. It’s entirely up to you and when you want to receive the message.
Brandon
thanks again for the help- I finally realized that I could combine a gauge or toggle widget with a button trigger that wold actually send a command. While I had wanted an automatic trigger on variable change, this is perfectly fine.
Ah, I understand now. The Input Control block works by first placing controls, but by themselves they don’t do anything. The controls expose variables that can the be used by the button to perform an action. We’ll look into ways to make that more clear. Thanks!