{"id":34,"date":"2015-10-13T03:45:14","date_gmt":"2015-10-13T03:45:14","guid":{"rendered":"http:\/\/www.beer.org\/beerblog\/?p=34"},"modified":"2015-12-30T03:45:43","modified_gmt":"2015-12-30T03:45:43","slug":"mqtt-config","status":"publish","type":"post","link":"https:\/\/www.beer.org\/blog\/index.php\/2015\/10\/13\/mqtt-config\/","title":{"rendered":"MQTT Config"},"content":{"rendered":"<h1 class=\"entry-title\"><a href=\"https:\/\/www.beer.org\/blog\/mqtt-config.html\">MQTT Config<\/a><\/h1>\n<footer class=\"post-info\"><abbr class=\"published\" title=\"2015-10-13T08:38:49\"> Published: Tue 13 October 2015 <\/abbr><\/p>\n<address class=\"vcard author\">By <a class=\"url fn\" href=\"https:\/\/www.beer.org\/blog\/author\/herb-peyerl.html\">Herb Peyerl<\/a><\/address>\n<p>In <a href=\"https:\/\/www.beer.org\/blog\/category\/phrobs.html\">Phrobs<\/a>.<\/p>\n<\/footer>\n<p>So as I work to integrate MQTT into my automation environment, I find myself wishing for some sort of device discovery mechanism. Possibly also a device configuration mechanism.<\/p>\n<p>Here&#8217;s the problem as I see it.<\/p>\n<p>If I know the topic of a device, I can subscribe to it and I can even get its last data. I can also subscribe to all topics or a subset of topics. But then I have to wait for a device to publish something in order to discover it.<\/p>\n<p>Unfortunately, I can&#8217;t ask <a href=\"http:\/\/mosquitto.org\/\">Mosquitto<\/a> what devices it knows about.<\/p>\n<p>There are many use-cases where this just isn&#8217;t sufficient:<\/p>\n<ul>\n<li>A device that isn&#8217;t publishing when you reboot.<\/li>\n<li>A device that is turned off and only publishes when it gets turned on (like a device that uses a tilt sensor to power itself on).<\/li>\n<li>A device that doesn&#8217;t publish at all (a subscribe only device like a Relay).<\/li>\n<\/ul>\n<p>It would also be nice to be able to re-configure some attributes of a device though I can see how this could be abused in an InternetOfThings scenario.<\/p>\n<p>So I believe I&#8217;m going to define a &#8216;discovery&#8217; record and experiment with that. I&#8217;m thinking something like this:<\/p>\n<p>\/Device_ID\/config\/[Name]\/[Attribute]\/[Value]<\/p>\n<p>Examples:<\/p>\n<pre>\/Kitchen\/config\/Temperature\/type\/int\r\n\/Kitchen\/config\/Temperature\/direction\/input\r\n\/Kitchen\/config\/Temperature\/unit\/celsius\r\n\/Kitchen\/config\/Humidity\/type\/float\r\n\/Kitchen\/config\/Humidity\/direction\/input\r\n\/Kitchen\/config\/Humidity\/unit\/percent\r\n\/Garage\/config\/Relay\/type\/bool\r\n\/Garage\/config\/Relay\/direction\/output\r\n\/Garage\/config\/RelayToggle\/type\/int\r\n\/Garage\/config\/RelayToggle\/direction\/output\r\n\/Garage\/config\/RelayToggle\/unit\/seconds\r\n\/Garage\/config\/Relay\/type\/bool\r\n\/Garage\/config\/Relay\/direction\/input\r\n<\/pre>\n<p>This tells me that is a sensor named &#8220;Kitchen&#8221; that publishes a temperature as an int in degrees celsius&#8230; There&#8217;s also a control named &#8220;Garage&#8221; that publishes a &#8220;Relay&#8221; state but it also has an output that it subscribes to called &#8220;Relay&#8221;&#8230; They both provide\/take a boolean. There&#8217;s also a control named &#8220;Garage&#8221; that subscribes to &#8220;RelayToggle&#8221; that will conceivably cycle a relay on\/off or off\/on for some number of seconds.<\/p>\n<p>I&#8217;ll experiment with that and see if I can make it useful&#8230; It will allow me to maintain an inventory of devices that are available&#8230; I will have to come up with some sort of expiry mechanism of course and if an attribute changes, I&#8217;ll need to override the old config with the new one presumably.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>MQTT Config Published: Tue 13 October 2015 By Herb Peyerl In Phrobs. So as I work to integrate MQTT into my automation environment, I find myself wishing for some sort of device discovery mechanism. Possibly also a device configuration mechanism. Here&#8217;s the problem as I see it. If I know the topic of a device,&#8230; <a class=\"moretag\" href=\"https:\/\/www.beer.org\/blog\/index.php\/2015\/10\/13\/mqtt-config\/\">Continue reading &raquo;<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-34","post","type-post","status-publish","format-standard","hentry","category-phrobs"],"_links":{"self":[{"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/posts\/34","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=34"}],"version-history":[{"count":3,"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/posts\/34\/revisions"}],"predecessor-version":[{"id":37,"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/posts\/34\/revisions\/37"}],"wp:attachment":[{"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.beer.org\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}