Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Michael, I'm new to the mcsMQTT logs, but this seems to confirm that the client never connects. May I know your thoughts as to why that might be? Thanks.

    Comment


      The code segment below is what is of interest. Your debug contains the line highlighted in red. Your debug does not contain those highlighted in blue. This seems to means that line in green never returns a result, nor does is raise an exception. This line is executed in the library code m2mqttt.dll. There is something blocking its completion, but I do not have insight into what it may be. Ever ten seconds the connect attempt is repeated but a connection is never made.

      I have a Hometroller Pi Hub that I never powered up. It should have a HS4 image similar to yours. If I have time tomorrow I will connect it up and see if it works for me or has issues similiar to yours.

      Another thing you can try is to use the internal broker rather than Mosquitto for testing. For the test all we are trying to determine is if the mcsMQTT client can connect to the mcsMQTT broker. To run this test stop Mosquitto so port 1883 becomes available. Remove the Mosquitto IP from the mcsMQTT broker setup and leave the text box blank. Best to restart the plugin so broker connection attempt will be a clean start. The Statistics tab will show if a connection is made or not.

      Code:
      If bFirstPass(iBroker) Then
      [COLOR=#c0392b]hsWritelog(PLUGIN_DEBUG, "MQTT Thread Client ID=" & clientId)[/COLOR]
      End If
      [COLOR=#c0392b]hsWritelog(PLUGIN_DEBUG, "Calling MQTT Connect")[/COLOR]
      sLine = "10"
      
      Try
      [COLOR=#c0392b]hsWritelog(PLUGIN_DEBUG, "Pre-connect oMQTTClient(" & iBroker.ToString & ") is Nothing=" & (oMQTTClient(iBroker) Is Nothing).ToString)[/COLOR]
      sLine = "10.0"
      Dim sUserName As String
      Dim sPassword As String
      If gMQTTBrokerUsername(iBroker) Is Nothing Then
      sUserName = gMQTTBrokerUsername(0)
      Else
      sUserName = gMQTTBrokerUsername(iBroker)
      End If
      If gMQTTBrokerPassword(iBroker) Is Nothing Then
      sPassword = gMQTTBrokerPassword(0)
      Else
      sPassword = gMQTTBrokerPassword(iBroker)
      End If
      [COLOR=#27ae60]iBrokerResponse = oMQTTClient(iBroker).Connect(
      clientId,
      sUserName,
      sPassword,
      gDefaultRetain,
      gDefaultQOS,
      True,
      gLWTTopic(iBroker),
      "Offline",
      True,
      60) [/COLOR]
      sLine = "10.0.1"
      If bFirstPass(iBroker) Then
      [COLOR=#2980b9]hsWritelog(PLUGIN_DEBUG, "MQTT Thread Broker " & (iBroker + 1).ToString & " " & gMQTTBroker(iBroker) & " Connect Response=" & iBrokerResponse.ToString)[/COLOR]
      For Each Relay As TCPRelay In TCPRelayDictionary.Values
      Relay.ReportStatus(True)
      Next
      End If
      
      Catch ex As Exception
      sLine = "10.5"
      If gDebugLog Then
      Dim sErr As String
      If gMQTTBroker(iBroker) IsNot Nothing Then
      sLine = "10.5"
      sErr = gMQTTBroker(iBroker).ToString
      Else
      sErr = "Null"
      End If
      Dim sEx As String
      If ex.InnerException Is Nothing Then
      sEx = ""
      Else
      sEx = ":" & ex.InnerException.Message
      End If
      [COLOR=#2980b9]hsWritelog(PLUGIN_DEBUG, "StartMQTT Connection attempt to Broker " & (iBroker + 1).ToString & " " & sErr & " " & ex.Message & sEx)[/COLOR]
      End If
      sLine = "10.7"
      oMQTTClient(iBroker) = Nothing
      End Try

      Comment


        Michael, thanks for the helpful info. I shut down mosquitto, nulled the broker fields in mcsMQTT General tab, restarted the plugin, and ran a test Alexa did not play the desired TTS. Here is the new log snippet:

        9/30/2020 9:00:48 PM 90483312 | Pre-connect oMQTTClient(0) is Nothing=False
        9/30/2020 9:00:49 PM 90484392 | Page Timing Start
        9/30/2020 9:00:49 PM 90484409 | Page Timing End
        9/30/2020 9:00:55 PM 90490384 | Spawning Internal MQTT Broker
        9/30/2020 9:00:58 PM 90493315 | Calling MQTTclient for Broker 1
        9/30/2020 9:00:58 PM 90493315 | Calling MQTT Connect
        9/30/2020 9:00:58 PM 90493315 | Pre-connect oMQTTClient(0) is Nothing=False
        9/30/2020 9:00:58 PM 90493412 | MQTT Broker 1 Connection Accepted, Connected=True to broker 127.0.0.1
        9/30/2020 9:00:58 PM 90493424 | MQTT Thread Subscribing
        9/30/2020 9:00:58 PM 90493449 | MQTT Subscription Start for Broker 1
        9/30/2020 9:00:58 PM 90493449 | MQTT Subscription Topics being selected for Broker 1
        9/30/2020 9:00:58 PM 90493450 | MQTT Subscription Topics selected for Broker 1
        9/30/2020 9:00:58 PM 90493454 | MQTTSubscribe List / Option=0 to
        9/30/2020 9:00:58 PM 90493454 | #
        9/30/2020 9:01:19 PM 90513908 | HSEvent VALUE_CHANGE| 1024| E2C2B1F3-004-Q47| 75.2| 77.1| 141
        9/30/2020 9:01:38 PM 90533545 | Shutdown IO

        Comment


          More observations: If I clear the two broker config fields in mcsMQTT General prop page in HS4 and restart the plugin, the fields don't stay cleared. At least the port number returns. If I then run netsat-a, I don't see the localhost listening on port 1883.

          Comment


            PS C:\Windows\system32> netstat -a

            Active Connections

            Proto Local Address Foreign Address State
            TCP 0.0.0.0:135 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:445 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:808 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:1880 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:3456 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:5040 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:5357 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:7680 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:8081 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:9001 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:49664 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:49665 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:49666 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:49667 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:49668 DESKTOP-O6D6H52:0 LISTENING
            TCP 0.0.0.0:49670 DESKTOP-O6D6H52:0 LISTENING
            TCP 127.0.0.1:1880 DESKTOP-O6D6H52:62245 ESTABLISHED
            TCP 127.0.0.1:43227 DESKTOP-O6D6H52:0 LISTENING
            TCP 127.0.0.1:62245 DESKTOP-O6D6H52:1880 ESTABLISHED
            TCP 192.168.0.20:139 DESKTOP-O6D6H52:0 LISTENING
            TCP 192.168.0.20:1880 192.168.0.19:34652 FIN_WAIT_2
            TCP 192.168.0.20:51754 192.168.0.14:rtsp ESTABLISHED
            TCP 192.168.0.20:51755 192.168.0.11:http ESTABLISHED
            TCP 192.168.0.20:51756 192.168.0.12:rtsp ESTABLISHED
            TCP 192.168.0.20:54021 sfo07s26-in-f10:https ESTABLISHED
            TCP 192.168.0.20:54025 52.242.211.89:https ESTABLISHED
            TCP 192.168.0.20:54320 a23-202-61-90:https ESTABLISHED
            TCP 192.168.0.20:54540 login:https ESTABLISHED
            TCP 192.168.0.20:54788 52.94.232.230:https ESTABLISHED
            TCP 192.168.0.20:55256 192.168.0.10:rtsp ESTABLISHED
            TCP 192.168.0.20:56818 192.168.0.13:rtsp ESTABLISHED
            TCP 192.168.0.20:57391 server-13-35-121-103:https CLOSE_WAIT
            TCP 192.168.0.20:59306 FOLSOMNAS:microsoft-ds ESTABLISHED
            TCP 192.168.0.20:61294 192.168.0.19:ssh ESTABLISHED
            TCP 192.168.0.20:62754 192.168.0.15:rtsp ESTABLISHED
            TCP [::]:135 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:445 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:808 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:3456 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:5357 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:7680 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:8081 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:9001 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:49664 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:49665 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:49666 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:49667 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:49668 DESKTOP-O6D6H52:0 LISTENING
            TCP [::]:49670 DESKTOP-O6D6H52:0 LISTENING
            TCP [2601:204:c001:e5d0:75fe:24cc:399d:7793]:54055 [2607:f8b0:4023:c06::bc]:5228 ESTABLISHED
            TCP [2601:204:c001:e5d0:75fe:24cc:399d:7793]:54329 lax17s15-in-x0a:https CLOSE_WAIT
            TCP [2601:204:c001:e5d0:75fe:24cc:399d:7793]:54458 e1:https ESTABLISHED
            UDP 0.0.0.0:3702 *:*
            UDP 0.0.0.0:3702 *:*
            UDP 0.0.0.0:3702 *:*
            UDP 0.0.0.0:3702 *:*
            UDP 0.0.0.0:5050 *:*
            UDP 0.0.0.0:5353 *:*
            UDP 0.0.0.0:5353 *:*
            UDP 0.0.0.0:5353 *:*
            UDP 0.0.0.0:5353 *:*
            UDP 0.0.0.0:5353 *:*
            UDP 0.0.0.0:5355 *:*
            UDP 0.0.0.0:56556 *:*
            UDP 0.0.0.0:57517 *:*
            UDP 0.0.0.0:59059 *:*
            UDP 0.0.0.0:59795 *:*
            UDP 0.0.0.0:62047 *:*
            UDP 0.0.0.0:64386 *:*
            UDP 127.0.0.1:1900 *:*
            UDP 127.0.0.1:49664 *:*
            UDP 127.0.0.1:64693 *:*
            UDP 192.168.0.20:137 *:*
            UDP 192.168.0.20:138 *:*
            UDP 192.168.0.20:1900 *:*
            UDP 192.168.0.20:64692 *:*
            UDP [::]:3702 *:*
            UDP [::]:3702 *:*
            UDP [::]:3702 *:*
            UDP [::]:3702 *:*
            UDP [::]:5353 *:*
            UDP [::]:5353 *:*
            UDP [::]:5353 *:*
            UDP [::]:5355 *:*
            UDP [::]:56556 *:*
            UDP [::]:57517 *:*
            UDP [::]:59059 *:*
            UDP [::]:59796 *:*
            UDP [::]:64387 *:*
            UDP [::1]:1900 *:*
            UDP [::1]:64691 *:*
            UDP [fe80::91c:2ea3:c3c7:37f9%3]:1900 *:*
            UDP [fe80::91c:2ea3:c3c7:37f9%3]:64690 *:*
            PS C:\Windows\system32>

            Comment


              Last for tonight: If I check node-red, the mqtt-in node, configured to connect to localhost on port 1883, is stuck on "connecting". It is not successfully connecting to mcsMQTT.

              Comment


                Port will be set to 1883 even if you clear it. The debug output using the mcsMQTT broker is normal showing connection made and subscription to all messages.

                The inability of Node Red to connect to the mcsMQTT broker is a reflection that there is something blocking the communications on at least port 1883 on localhost. Did you try to use the actual IP of the computer (e.g. 192.168.0.20) rather than localhost? How about firewalls? I am not a networking engineer so have limited knowledge of what could prevent the communications.

                Comment


                  I have a Hometroller Pi Hub that I never powered up. It should have a HS4 image similar to yours. If I have time tomorrow I will connect it up and see if it works for me or has issues similiar to yours.
                  I fired up the Hometroller Pi Hub and went through all the registration steps. HS 4.1.1.0 is what was installed at the factory. I went through the following steps
                  1. apt-get update which resulted in some mono updates.
                  2. mosquitto with apt-get mosquitto, apt-get mosquitto-clients
                  3. mcsMQTT from HS Updater with version 5.2.2.0 shown running after enabling it
                  4. with test mqtt application on Windows computer connected to mqtt broker on Hometroller Pi Hub
                  4. configured mcsMQTT broker to localhost
                  5. viewed statistics tab and broker connection showed to be online, LWT messages appears in Windows test mqtt application
                  6.installed node-red with script
                  bash <(curl -sL https://raw.githubusercontent.com/no...js-and-nodered)
                  7. setup node-red with mqtt broker of localhost, green "connected" icon shows on the mqtt node in the flow, node-red connected status shows in Hometroller Pi Hub console

                  This process confirms there is nothing inherent in the stock HST RPi that blocks network traffic on port 1883.

                  Comment


                    Michael, thanks. Just covering bases, I did 2 restarts of the Zee S2 controller. After the second, port 1883 opened, and everything now works. Suggestion: Adding some FAQs with methodical diagnosis steps. These might include the use of netstat and checking for port 1883 listening on the HS controller, which could be on several common hardware platforms.

                    Comment


                      The past weekend I started over and installed HS4 fresh. I plan to export/import data over MQTT to/from Home Assistant and started to setup publish/subscribe for a couple of Z-Wave dimmer devices yesterday through a Mosquito broker in Home Assistant.

                      Publish is no issue at all, works right away, but subscribe is very tricky to get working. I use the same topic but add "/set" in the end of the topic when I want to initiate a change from Home Assistant. I verify that everything looks ok by using MQTT Explorer. Sometimes the device in HomeSeer is not updated at all, sometimes it takes several minutes. I thought I had solved this matter by choosing "Express" but for the next device I set up this didn't help.

                      After restarts of the PI and HomeSeer I finally got it to work, but I don't know exactly what did solve the issue. Though, when it finally works it keeps on doing so, so it feels like it is something in the configuration process that is not working.

                      What I've tested:

                      - Add Express option
                      - Avoid copying/pasting the topic between the publish and subscribe fields in mcsMQTT but enter the topic manually
                      - Restart mcsMQTT repeatedly
                      - Restart HomeSeer repeatedly

                      Happy for any suggestions what to test to make subscribe smoother as I have added four devices this far and have a long way to go.

                      Edit: Just added another one and a restart of the PI was needed to make it receive/accept values.

                      Comment


                        A topic that is received from HA (via broker) that has been setup as a non-plugin subscription such as for an existing HS Zwave device will result in mcsMQTT making a request to HS which will then forward the request to the Zwave plugin. The Zwave plugin will use Zwave via the hardware interface to request the end point (e.g. Zwave bulb) to change per the request. The Zwave bulb will report back an updated status that will be routed through the HS Zwave interface to the Zwave plug-in and then to HS to update the HS status. HS will notify any plug-in interested (e.g. mcsMQTT) in status changes (via HSEvent API). mcsMQTT will forward the status via the publish topic that is setup to the MQTT broker from where HA, if subscribed to the topic being published by mcsMQTT, will receive this topic and update HA status.

                        The debug file that is produced in \Data\mcsMQTT\mcsMQTT Debug.txt will contain a record of the parts of this transaction that involve mcsMQTT. The HS log will also contain some of its involvement. I do not know what type of Zwave plugin debug information is available.

                        Express option limits capability as a tradeoff for CPU efficiency. It should not have an effect on your observations.

                        Copy/Paste vs. retyping also will have no effect, but do note that the publish an subscribe topic need to be different so if not modified after copy/paste the communication chain will be broken by mcsMQTT because it does not want to incur a continuous circular stream of messages.

                        Restarting the plug-in or HS has the effect of total initialization vs. incremental change. It is possible this could have an effect, but it is not the design intent. Specific data such as is contained in the debug file should provide insight.

                        It is also better to start a new thread in the forum with an appropriately titled subject so that future users may be able to benefit from the discussion. Otherwise it gets lost in a 32 page thread.

                        Comment


                          Question about events triggering with "MQTT topic timout "

                          I am trying to set an event to notify me if a specific topic was not received for the last X minutes. I have followed the manual and set up the following event:

                          Click image for larger version  Name:	node-red-1.PNG Views:	0 Size:	157.7 KB ID:	1441500

                          after setting the event, I made sure that the plugin was catching the topic and I created a HS device with a timestamp:

                          Click image for larger version  Name:	node-red-2.PNG Views:	0 Size:	113.0 KB ID:	1441501
                          I manually published to the topics, waited 3 minutes,made sure nothing was published to the topic meanwile and still the event is not triggered.

                          Am I missing something here ?

                          Comment


                            The trigger you setup is for a topic that has at least three components Node-Red, heartbeat, and anything else.
                            The device is subscribed to a topic that has two components Node-Red and heartbeat.
                            If you remove the /# from the trigger than you should get what you want.

                            Comment


                              Originally posted by goldriver View Post
                              Question about events triggering with "MQTT topic timout "

                              I am trying to set an event to notify me if a specific topic was not received for the last X minutes. I have followed the manual and set up the following event:

                              Click image for larger version Name:	node-red-1.PNG Views:	0 Size:	157.7 KB ID:	1441500

                              after setting the event, I made sure that the plugin was catching the topic and I created a HS device with a timestamp:

                              Click image for larger version Name:	node-red-2.PNG Views:	0 Size:	113.0 KB ID:	1441501
                              I manually published to the topics, waited 3 minutes,made sure nothing was published to the topic meanwile and still the event is not triggered.

                              Am I missing something here ?
                              I use other method to check if nodered( and others ) are online.

                              I didn’t know this option. That’s creative an easy to implement .

                              Thanks to you both

                              Comment


                                Originally posted by Michael McSharry View Post
                                The trigger you setup is for a topic that has at least three components Node-Red, heartbeat, and anything else.
                                The device is subscribed to a topic that has two components Node-Red and heartbeat.
                                If you remove the /# from the trigger than you should get what you want.
                                Unfortunatly, I had already tried without the /# and it is not working either.

                                Should I see anything in the debug file that would give me some hints on the issue ? because I don't !

                                Comment

                                Working...
                                X