![\"Screenshot](\"https:\/\/i0.wp.com\/grodansparadis.com\/wordpress\/wp-content\/uploads\/2016\/02\/Screenshot-from-2016-02-14-224416.png\")
<\/a><\/p>\nThe MQTT driver for the VSCP Daemon<\/a> is a way to connect VSCP\u00a0 to things communicating over MQTT.\u00a0 Well it’s just as easy as 1-2-3 to do so. Just follow this instruction.<\/p>\n Suppose that we want two MQTT channels. One that publish content to a broker and one that subscribe content from a broker channel. Of course we can have as many as we like. Just add more driver entries if you need more. There is no practical limit.<\/p>\n So for driver additions we add the following driver enteries to the vscpd.conf file (\/etc\/vscp\/vscpd.conf<\/em> on Linux and \/programdata\/vscp\/vscpd.conf<\/em> on windows).<\/p>\n <!– Level II MQTT driver –><\/strong><\/em> <!– Level II MQTT driver –><\/strong><\/em> Both have there own unique names, MQTT1 and MQTT2 as they should. Paths are set to the driver location. Windows user need to point this path to the installation folder. The GUID is set to all zeros meaning the driver will use the GUID of the interface. We are fine with that in this sample but for most cases it is better to set a unique GUID.<\/p>\n Then we have the configuration string and it is different for the two driver entries. We look at each driver on its own from here,<\/p>\n The configuration string looks like this<\/p>\n session1;subscribe;vscp-sub;192.168.1.9:1883<\/strong><\/em><\/p>\n That is we create a subscription channel, that is a channel which subscribes on content from a MQTT broker, and in this case expects VSCP events on the standard text form<\/a> coming in on the channel. The broker is at IP-address 192.168.1.9 and using the\u00a0 standard port 1883. The topic we are interested in is vscp_sub<\/strong>.\u00a0 That’s almost it. We need one more thing. We need to name the session for our communication with the MQTT broker. In this case we set the session name to session1<\/strong><\/em>.\u00a0 Remember that this session name must be unique in each driver entry.<\/p>\n Restating the daemon and we are ready to go<\/p>\n Using\u00a0 mosquitto_pub<\/a> we can now send MQTT events to the VSCP system<\/p>\n mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,10,6,0,0,-,0x88,0x82,0x0A,0x09”<\/strong><\/em><\/p>\n which comes in as 25.68 degrees Celsius from sensor 1.<\/p>\n Data<\/strong><\/p>\n This section can be skipped if your not interested in how the data is coed.<\/em><\/p>\n This format is fully described in the data coding section of the specification<\/a> but we give a brief explanation of the event data here also (but you should read the spec. for a comprehensive understanding).\u00a0 The event is CLASS1. MEASUREMENT, Type=6, Temperature<\/a>. So we have a temperature measurement. Good to know.<\/p>\n It is a VSCP level I events. We see that from CLASS1. in the class name. This is a low end measurement event used in VSCP that can handle all SI system<\/a> defined types.\u00a0 VSCP level I event have a maximum of eight data bytes as it is defined to be possoble to be handled by the smallest devices out there. Eight byte is not much but you can tell what type of measurement it is, what sensor of eight possible on a board it comes from, and what unit the measurement is give in. Not bad. Compare that to just sensing 44.20 over the topic.<\/p>\n The data can be coded as a string or a floating point value or in something called a normalized integer<\/strong> as here. If your device can handle floating point you should use that. But many devices does not have resources to handle floating point data as it costs memory. They ned the memory for other tasks. And that is where the normalized integer comes in handy.<\/p>\n As you see the data for the measurement is<\/p>\n 0x88, 0x82, 0x0A, 0x09<\/strong><\/em><\/p>\n The first byte of this data\u00a0 is the coding byte, here 0x88. In this byte fits information about the index for the sensor\u00a0 (bits 0,1,2), the the unit\u00a0for the measurement (bits 3,4) and the type of data that follows (bits 5,6,7).<\/p>\n So in binary 0x88 is<\/p>\n 10001000<\/strong><\/p>\n which if we break apart the different fields become<\/p>\n 100 01 000<\/strong><\/p>\n OK We have a measurement value from sensor 0 that is expressed as degrees Celsius. Just need to know the value as well.<\/p>\n A normalized integer have a decimal point shift byte as its second byte and then the\u00a0 1-6 bytes that follow are the actual integer value. So here the value is 0x0A09 (VSCP always store everything MSB first). Translated to decimal 0x0A09\u00a0 is 2569.<\/p>\n The second data byte (0x82) says, if it has bit seven set,\u00a0 that the decimal point should be moved left in the number that follows with the amount told by the remaining bits. So in this case the decimal point should move two steps to the left which gives 25.62.<\/p>\n So the measurement value is a temperature measurement of 25.69 degrees Celsius.<\/p>\n Sending on\/off<\/strong><\/p>\n Everything is well specified in VSCP.\u00a0 So to turn something on or off is well specified of course.<\/p>\n To tun something ON one use the CLASS1.CONTROL, Type=5 <\/a>in VSCP.\u00a0 To turn something off one use CLASS1.CONTROL, Type=6<\/a>.<\/p>\n The event CLASS1.CONTROL is coded as 30.<\/p>\n Now to something that might look strange to VSCP newcomers at first. VSCP normally does not address things.\u00a0 WHAT!? you might scream out. Yes it does not. Instead it send a TurnOn event to devices in a zone\/subzone. The sender does not know if the receiver is one or as man as hundred devices. It does not even care. It just send the event. It trust the transport mechanism to deliver the event to interested parties.<\/p>\n So for both TurnOn and TurnOff of the data format is<\/p>\n 0x00, zone, subzone<\/strong><\/p>\n So to turn something on in zone=1\/subzone=2 we send<\/p>\n mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,30,5,0,0,-,0,1,2”<\/strong><\/em><\/p>\n and to turn something off we send<\/p>\n mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,30,6,0,0,-,0,1,2”<\/strong><\/em><\/p>\n Not to hard is it?<\/p>\n The configuration string looks like this<\/p>\n session2;publish;vscp-pub;192.168.1.9:1883<\/strong><\/em><\/p>\n Well we recognize the confoguration string from above. The session name is “session2”. Remember it should be unique. and we publish to a broker instead of subscribing. The MQTT topic is set to vscp_pub.<\/p>\n So to if you subscribe to vscp_pub on the broker you get events from the VSCP system sent to you.\u00a0 You set filters to tell which events you want and do many other things.<\/p>\n Using the mosquitto_sub subscribing is<\/p>\n mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’<\/strong><\/p>\n which you can use for testing. But Arduino or Raspberry Pi also have MQTT libraries so you can take in VSCP events to them to, well or sening\u00a0 giving you access to the VCSP framework with web interfaces, diagrams, message routing and a lot more.<\/p>\n It may be simpler to use just VSCP and get the same advantages but this write-up is for those of you that use MQTT today.<\/p>\n Another part will follow describing a way to simplify message handing over MQTT.<\/p>\n
\n\u00a0\u00a0\u00a0 <driver enable=”true” ><\/strong><\/em>
\n\u00a0\u00a0\u00a0 <name>MQTT1<\/name><\/strong><\/em>
\n\u00a0\u00a0\u00a0 <path>\/usr\/local\/lib\/vscpl2drv_mqtt.so<\/path><\/strong><\/em>
\n\u00a0\u00a0\u00a0 <config>session1;subscribe;vscp-sub;192.168.1.9:1883<\/strong><\/em>
\n\u00a0\u00a0 <guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00<\/guid><\/strong><\/em>
\n <\/driver><\/strong><\/em><\/p>\n
\n <driver enable=”true” ><\/strong><\/em>
\n\u00a0\u00a0\u00a0 <name>MQTT2<\/name><\/strong><\/em>
\n\u00a0\u00a0\u00a0 <path>\/usr\/local\/lib\/vscpl2drv_mqtt.so<\/path><\/strong><\/em>
\n\u00a0\u00a0\u00a0 <config>session2;publish;vscp-pub;192.168.1.9:1883<\/strong><\/em>
\n\u00a0\u00a0\u00a0 <guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00<\/guid><\/strong><\/em>
\n <\/driver><\/strong><\/em><\/p>\nMQTT1<\/h2>\n
<\/a><\/p>\n\n
MQTT1<\/h2>\n