Announcement

Collapse
No announcement yet.

Excessive CPU and Excessive MQTT Topics

Collapse
X
 
  • Filter
  • Time
  • Show
"shutdown"
Clear All
new posts

  • #1
    The main loop in the plugin is like the one provided in the SDK with the snipit shown below. The plugin establishes a socket connection to HS and then sits in a tight wait loop monitoring the connection. If the connection is lost the plugin will command the ShutdownIO call to do a clean shutdown and then end. HS would then see the plugin disconnected at its next API call which in these two cases were Name and InterfaceStatus and recognize the lost connection and try to start it up again.
    Code:
    client = ScsServiceClientBuilder.CreateClient(Of IHSApplication)(New ScsTcpEndPoint(sIp, 10400), oPlugin)
    client.Connect()
    Do
         Threading.Thread.Sleep(10)
    Loop While client.CommunicationState = HSCF.Communication.Scs.Communication.CommunicationStates.Connected And Not gShutdown
    So the question becomes why does the ScsServiceClientBuilder class think the socket connection has disconnected?

    An observation is that the ShutdownIO is always 4 or 5 milliseconds after the HS Name/InterfaceStatus call. It is as if the HS call is the event that caused the connection status to go to disconnected. No particular implications, but just an observation.

    What is the environment you are running HS and the plugin?

    As you can see from the snipit there is no tolerance for a disconnect status. There is no attempt to see if it persists for more than 10ms. There is no attempt by the plugin to reconnect once lost. We can try some of this, but have no idea what the implications may be as this is the template that was provided by HST.

    Code:
    4/1/2018 11:48:03 PM	2	| mcsMQTT Running at /usr/local/HomeSeer, HS is at /usr/local/HomeSeer 
    4/1/2018 11:48:03 PM	19	| mcsMQTT InitHW ComputerName= hometrollerSEL, IOEnabled=False 
    4/1/2018 11:48:03 PM	214	| MakeTable MQTT_MESSAGE Exists=True  
    4/1/2018 11:48:03 PM	215	| MakeTable MQTT_HISTORY Exists=True  
    4/1/2018 11:48:03 PM	220	| mcsMQTT Debug InitHW Database Ready 
    4/1/2018 11:48:03 PM	224	| mcsMQTT Debug Receive Ready 
    4/1/2018 11:48:03 PM	228	| mcsMQTT Debug Trigger Ready 
    4/1/2018 11:48:03 PM	322	| Spawning MQTT Threads  
    4/1/2018 11:48:03 PM	332	| mcsMQTT Debug MQTT Ready 
    4/1/2018 11:48:03 PM	332	| HW Init Complete  
    4/1/2018 11:48:03 PM	333	| MQTT Thread Started with broker 192.168.8.2, Shutdown=False, Disconnect=False, Client=False, Connected=False  
    4/1/2018 11:48:03 PM	333	| MQTT Thread Not Connected Yet  
    4/1/2018 11:48:03 PM	335	| Background Init Started  
    4/1/2018 11:48:03 PM	335	| Background Init Received  
    4/1/2018 11:48:03 PM	336	| Background Send  
    4/1/2018 11:48:03 PM	340	| MQTT Thread Client Created  
    4/1/2018 11:48:03 PM	341	| MQTT Thread Client ID=f909b4bb-db5c-4763-869f-579068473d22  
    4/1/2018 11:48:03 PM	347	| Background Init Filters - Background Complete  
    4/1/2018 11:48:03 PM	353	| HS Request Name  
    4/1/2018 11:48:03 PM	362	| MQTT Thread Broker 192.168.8.2 Connect Response=0  
    4/1/2018 11:48:03 PM	362	| MQTT Broker Connection Accepted, Connected=True  
    4/1/2018 11:48:03 PM	365	| MQTT Thread Subscribing   
    4/1/2018 11:48:03 PM	368	| MQTT Subscription Start  
    4/1/2018 11:48:03 PM	368	| MQTT Subscription Topics being selected  
    4/1/2018 11:48:03 PM	368	| MQTT Subscription Topics selected  
    4/1/2018 11:48:03 PM	370	| MQTTSubscribe List /  NoDiscovery=False to   
    4/1/2018 11:48:03 PM	370	| #  
    4/1/2018 11:48:16 PM	13545	| HS Request InterfaceStatus  
    4/1/2018 11:48:18 PM	15547	| HS Request InterfaceStatus  
    4/1/2018 11:48:19 PM	16697	| HS Request Name  
    4/1/2018 11:48:19 PM	16701	| Shutdown IO

    Comment

    Working...
    X