Mysensors MQTT gateway


  • Code Contributor

    Hello

    MQTT Gateway for mysensors.

    https://github.com/Damme/MyMQTT

    Requires mysensors lib 1.4b

    //Daniel


  • Mod

    How beautiful! MQTT support in only a fex hundred lines of C-code. Well done!
    I only had a quick look at it, but when I was implementing the MQTT gateway I tried to convert the message types etc. to text, you're converting them to a single ID-value (the AABBCCDD value), am I right?
    Where does this land in the MQTT tree?


  • Code Contributor

    @Yveaux Yes this is correct.

    I have not considerd MQTT tree yet, The only program I've tested MQTT on is openhab and it dont really care.
    I could have a fixed defined string in the code, and separating the node and sensor with /
    so, [FixedString]/04/01 for sensor 1 on node 4. I am thinking of just ignoring the Messagetype and subtype (command) (just using 1, C_SET).
    The only data that uses more messagetypes on one sensor gw.sendSketchInfo("Test Sensor", "1.0"); what I know of. They have subtype 3(C_INTERNAL) (could be ignored because they sends on sensor 255) and then only send I_SKETCH_NAME to MQTT, I_SKETCH_VERSION could be ignored and if this is important we could just move 1.0 onto the sketch name.
    ofcorse we could use MessageType and SubType also, something like "[FixedString]/04/01/01/01"

    are there any other MQTT client software's out there easy to use to check communication with the MQTTGateway?

    //Daniel


  • Mod

    @Damme said:

    are there any other MQTT client software's out there easy to use to check communication with the MQTTGateway?

    I have only tried mosquito so far, which is a broker, but come with command line tools mosquitto_pub and mosquitto_sub to resp. publish /subscribe.
    Works like a treat, also with my perl gateway implementation.

    There's also MQTT-sn, a work in progress, which specifically targets sensor networks - like we do.


  • Code Contributor

    @Yveaux I forgot to mention that this is also a Broker (Server) and openhab is the client.


  • Mod

    @Damme said:

    something like "[FixedString]/04/01/01/01"

    I would definitely split the address like you suggest. This is in line with MQTT hierarchical structure and allows subscription to subtrees etc.
    Using names instead of values also allows subscribing to e.g. all 'TEMP' values in a single run, which might be beneficial, depending on the application. It also helps in decoupling from MySensors details.
    If you find a way (manage to fit it in the atmega's memory) to translate the sensor types etc to textual presentations then please do so.


  • Code Contributor

    @Yveaux To include textual presentation:
    String PROGMEM s_presentation[] = {"S_DOOR", "S_MOTION", "S_SMOKE", "S_LIGHT", "S_DIMMER", "S_COVER", "S_TEMP", "S_HUM", "S_BARO", "S_WIND",
    "S_RAIN", "S_UV", "S_WEIGHT", "S_POWER", "S_HEATER", "S_DISTANCE", "S_LIGHT_LEVEL", "S_ARDUINO_NODE",
    "S_ARDUINO_REPEATER_NODE", "S_LOCK", "S_IR", "S_WATER", "S_AIR_QUALITY"};
    eats exacly 1592 extra bytes just for the definition (a bit more if we are going to write "S_TEMPERATURE" insted of only "S_TEMP")..
    My thought was almost to just skip those completly and just use [FixedString]/NodeID/SensorID .. In openhab I group stuff in the items-conf and can make groups like I wish, but other programs might work differently.. maybe I should install mosquito and see how they do..

    edit: should be "PROGMEM const char *string_table[] =" or something instead.. but the size shouldn't be much different, we are talking 1.5-2kB extra program size (5-7%)


  • Mod

    @Damme drop the 'S_' prefix saves you 2 bytes per item. I just managed to squeeze it In...

    That's when I figured I still have to do some 'glueing' somewhere on a more capable device (rpi, server,...) which could just as well directly talk to the unmodified ethernet or serial gateway from MySensors... So why go through all the hassle to squeeze it all in a small arduino?


  • Code Contributor

    Made some major changes, Too tired to write them down. It should be working to be tested out atleast. I have not implemented any auto node id designation yet. I have the code but have a bug to sort out first.

    new address is (openhab): {mqtt="<[my:MyMQTT/042/001/Temperature:state:default]"}

    and openhab supports wildcard ; {mqtt="<[my:MyMQTT/042/#/Humidity:state:default]"}
    for example.
    Definition is in MyMQTT.cpp


  • Hero Member

    @Damme said:

    String PROGMEM s_presentation[] = {"S_DOOR", "S_MOTION", "S_SMOKE", "S_LIGHT", "S_DIMMER", "S_COVER", "S_TEMP", "S_HUM", "S_BARO", "S_WIND",
    "S_RAIN", "S_UV", "S_WEIGHT", "S_POWER", "S_HEATER", "S_DISTANCE", "S_LIGHT_LEVEL", "S_ARDUINO_NODE",
    "S_ARDUINO_REPEATER_NODE", "S_LOCK", "S_IR", "S_WATER", "S_AIR_QUALITY"};
    eats exacly 1592 extra bytes just for the definition (a bit more if we are going to write "S_TEMPERATURE" insted of only "S_TEMP").

    I don't get why it would be that high - at a quick guess those 24 strings should use less than 300 bytes including the pointers and nul terminators. Are they being repeated many times or is there some additional library which gets pulled in when you use them?

    By the way, if you want the strings themselves in progmem (and not just the array of pointers to strings), I think you may need to use different techniques. http://arduino.cc/en/Reference/PROGMEM

    But that's about how much RAM you use; I still don't understand why those two dozen strings would take up 1.5 KBytes of flash.


  • Code Contributor

    @Zeph Using progmem already, made one custom function to read out the data and get length at the same time from a string array using index.

    I have been looking a ittle inside the mysensors lib and there are plenty of optimizations to be done.. I might put some time to clean stuff out!
    The exact size differance with and without the strings is ~880bytes, (I put som extra in there) but there are som functions inserted to handle them.


  • Code Contributor

    Omfg, I've spent the last week trying to figure out why some messages got sent and others didn't...
    I forgot the frekin "gw.process();" on the receiving end! D'oh!! 😐 >.< 😛
    Well, While dissecting the code I found some bugs I think I've sorted out now..

    So now I'll try to clean code up a bit and then I'll call it beta 0.1
    Anyone tried it?


  • Code Contributor

    And there we have it, beta 0.1
    should work. Please test it! 🙂
    I'll try to write better documentation as time comes. I'll answer any questions.


  • Code Contributor

    @Damme Fail on me, forgot to push the update.. 😛 Now it's there.


  • Hero Member

    Is this for 1.4 beta or 1.3?

    Just need another ethernet shield and to figure out how to get MQTT to work in Domoticz.


  • Code Contributor

    Its made for 1.4b




Log in to reply
 

Suggested Topics

0
Online

11.4k
Users

11.1k
Topics

112.7k
Posts