No announcement yet.

mcsMQTT does not retain REF of topics to devices across a reboot of HS3

  • Filter
  • Time
  • Show
Clear All
new posts

  • mcsMQTT does not retain REF of topics to devices across a reboot of HS3


    I am trying to update homeseer devices based on MQTT message containing thermostat temperatures for our house. The message are transmitted via mosquitto running on several linux nodes to homeseer, and I use mcsMQTT to associate the incoming topics with HS3 devices.

    This works fine as long as homeseer and the server it runs on remain up and running, but as soon as I reboot or restart homeseer, the association is lost and the devices are no longer updated when messages are received.

    The messages are of the form "magnoliamanor/temperature/<room-name>" and "magnoliamanor/temperature/<zone-number>" where room name will be something like "Loft" or "Bedroom" and zone number will be a digit 0-9.

    What should I look for to see why the associations are lost? The HS3 log file shows the mcsMQTT plugin starting successfully but not much else.

    You can see the messages on the mcsMQTT setup page image attached -- if I create the homeseer devices either by checking the A column or by using the Edit/Add tab, either way the association with a homeseer device is lost on restart. You can see an example on the associations tab where I check the A columns for the messages with room names. Once the association (REF box) is lost, if I try to add the reference back in I get a complaint that the device is owned by the mcsMQTT plugin.


    Best Regards,

    Mitch Mitchell

  • #2
    Here is an mcsMQTT Debug.txt file -- I stopped the server, cleared the debug file, then started the server and associated the "magnoliamanor/temperature/<name or number> messages with devices by checking the A column. Then I restarted the server and lost the associations to the devices. I've also attached a zip of the mcsMQTT.db file as well.
    Attached Files


    • #3
      Well it appears I may have solved the problem -- I removed the mcsMQTT db files, and started over and it appears to be working. BUT -- one thing I changed, is that while viewing some of the debug files I discovered that some messages published by my HVAC system carried payload with a carriage return ^M on the end of the message contents. I fixed that before I tried removing the mcsMQTT db files so that may have been the cause -- you should be able to see some of that in the db zip file I uploaded (but not in the debug file, I had fixed the problem before I captured that one).


      • #4
        I don't think the carriage return has any explicit negative impact other than what may show up in a HS device string and it may affect number values if they are ended with this special character.

        What I see in the database are rows of data with null values for many of the columns that have been added over various versions of the plugin. The other odd thing is that the only accepted message was device 566, but source was "#" which is a MQTT wildcard character meaning any topic.

        I am away for a couple weeks so not able to use your database file to evaluate the effects in my environment until I get back. The issue needs to be associated with what is saved in the database as that is where mcsMQTT goes to initialize on each start. Good that you were able to overcome the problem.


        • #5

          Thanks for your note. I was not using the messages that contained the ^M characters in HomeSeer anyway, it was for internal exchanges between node-red servers that are part of my home automation system. It just happened that I caught and fixed that problem before removing the database and restarting so I thought it might have some bearing.

          So I don't know if its really worth you looking further into it unless you just want to check on it to make things more bulletproof. I just happen to have a lot of MQTT traffic flying around in my servers and I really hadn't started seriously using the plugin until this week so it could have been something dumped into the MQTT bus a good while back that might have inflicted the problem.

          Best Regards,