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.
Announcement
Collapse
No announcement yet.
mcsMQTT Plugin
Collapse
This is a sticky topic.
X
X
-
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
-
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
-
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.
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.
- Likes 1
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:
after setting the event, I made sure that the plugin was catching the topic and I created a HS device with a timestamp:
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 ?
- Likes 1
Comment
-
Guest
Originally posted by goldriver View PostQuestion 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:
after setting the event, I made sure that the plugin was catching the topic and I created a HS device with a timestamp:
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 didn’t know this option. That’s creative an easy to implement .
Thanks to you both
Comment
-
Originally posted by Michael McSharry View PostThe 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.
Should I see anything in the debug file that would give me some hints on the issue ? because I don't !
Comment
Comment