Nowadays, most laboratory measuring tools have an RS232 port and/or a USB port, enabling you to drive them remotely. Usually, the manufacturers of this kind of instruments offer a proprietary software to drive them from a computer. This piece of software is usually more or less easy to use and not necessarily free. Obviously, it is tempting to get rid of the original software and to drive the devices on one's own. The question that we pondered this week was to know whether there was a universal way to drive this kind of equipment from an arbitrary software.
The Yoctopuce API has several distinct mechanisms to optimize access to the sensors, through USB as well as through the network. In a previous post, we talked about the polling and callback methods and compared their respective advantages. Today, we offer a new intermediary method, enabling you to optimize access to some sensor attributes, when you can't do it with a callback.
Node-RED is a visual programming language that can be used to connect various Web services, API or peripherals together. Node-RED can use data coming from a Web server, a MQTT broker, a mail server or even Twitter, but not from Yoctopuce sensors. That is, until yesterday...
Last year, Microsoft announced the Azure IoT Suite. Behind this somewhat pompous name hides two examples of use of their Azure cloud with connected objects. We are going to see how to use Yoctopuce modules in one of these two examples.
YoctoHubs can automatically publish sensor values on a MQTT broker, as we illustrated in a previous post on this topic. However, for scalability and security reasons, YoctoHubs cannot use MQTT messages to drive connected modules. There are however circumstances where it might be desirable to integrade Yoctopuce command devices in an existing MQTT architecture. In this case, it is enough to use a small gateway between the MQTT protocol and the Yoctopuce modules. This is what we are going to do this week.
1 2 3 4 5 6 ... 10 ... 15