Error message Unknown HubAction


#1

Is it possible to have HSM synced across devices? I’m thinking of moving my LAN security integration to a secondary hub (to try and eliminate it from causing potential the issues I’m having on my primary hub). I don’t see a way to install the integration (which links to HSM) in this sort of setup.

I’m at my wits end trying to figure out where these are coming from (which aren’t accessible by me and provided by support). Next up is to mirror the network port and try and capture ingress/egress traffic.

Line 5304: 2019-08-20 01:05:45.147 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5305: 2019-08-20 02:45:30.651 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5306: 2019-08-20 05:15:17.483 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5307: 2019-08-20 06:40:04.729 [zwProcessPool-thread-02] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5320: 2019-08-20 09:24:12.825 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5321: 2019-08-20 10:34:08.580 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5323: 2019-08-20 13:31:22.029 [zwProcessPool-thread-02] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5324: 2019-08-20 14:26:30.890 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5395: 2019-08-20 17:37:58.751 [zwProcessPool-thread-02] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5396: 2019-08-20 18:19:01.992 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5694: 2019-08-20 21:45:23.523 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5695: 2019-08-20 22:11:53.716 [zwProcessPool-thread-02] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5696: 2019-08-21 01:53:46.594 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5697: 2019-08-21 02:05:27.714 [zwProcessPool-thread-02] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5704: 2019-08-21 05:59:32.307 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408
 Line 5705: 2019-08-21 06:02:50.268 [zwProcessPool-thread-01] WARN  com.hubitat.hub.service.LanService - Unknown HubAction: 8408

Link to Hub
#2

You're asking the question in a Link to Hub topic and for it, the answer is no.

To find a YES answer though, you need only look at HubConnect. :slight_smile:


#3

You are sending a zwave hub action "8408" but not specifying the Protocol of the HubAction so it defaults to LAN. You are effectively trying to send a zwave command over the lan.


#4

Thank you, Chuck. To clarify, this error is coming from a driver or app that is doing a HubAction call and not sending all the right information and it's unrelated to any process on Hubitat receiving data (like lanparsemessage).

I've verified my Drivers/Apps all have legitimate HubAction calls:

  private getHostAddress() {
    def ip = settings.ip
    def port = settings.port

	if (logEnable) log.debug "Using ip: ${ip} and port: ${port} for device: ${device.id}"
    log.debug "Using ip: ${ip} and port: ${port} for device: ${device.id}"
    return ip + ":" + port
}

def sendData(message) {
    sendEthernet(message) 
}

def sendEthernet(message) {
    if (message.contains(" ")) {
        def parts = message.split(" ")
        def name  = parts.length>0?parts[0].trim():null
        def value = parts.length>0?parts[1].trim():null
        message = name + "%20" + value
    }
	if (logEnable) log.debug "Executing 'sendEthernet' ${message}"
    log.debug "Executing 'HubAction ${message}"
	if (settings.ip != null && settings.port != null) {
    	new hubitat.device.HubAction(
    		method: "POST",
    		path: "/${message}?",
    		headers: [ HOST: "${getHostAddress()}" ]
		)
    }
    else {
    	log.warn "Parent HubDuino Ethernet Device: Please verify IP address and Port are configured."    
    }
}

and

private sendCommand(path) {
 ifDebug("send command: ${path}")

if (settings.proxyAddress.length() == 0 ||
   settings.proxyPort.length() == 0) {
   ifDebug("SmartThings Node Proxy configuration not set!")
   return
}

def host = getProxyAddress()
def headers = [:]
headers.put("HOST", host)
headers.put("Content-Type", "application/json")
headers.put("stnp-auth", settings.authCode)
log.debug "hubAction GET ${path} sent to ${host}"
def hubAction = new hubitat.device.HubAction(
   method: "GET",
   path: path,
   headers: headers
)
sendHubCommand(hubAction)
}

Any other thoughts on how to debug this issue? Let me know if want to take this discussion off-line or in another thread since this is off-topic from Link To Hub.


#5

Do you have any custom zwave drivers? Probably a battery powered device since 8408 is "wake up no more information"


#6

Looks like it's either:

This: hubitat/WAPIRZ-1.groovy at master · bdwilson/hubitat · GitHub
Or This: GoControl (and sim) Contact Sensor

Should I just see if a default driver will work? For WAPIRZ-1, I assume I used this because of the configuration option to have it reset period of 1 minute after motion stopping.

Thank you, btw. I was barking up the wrong tree thinking it was a LAN device causing the issue.


#7

I think they both need fixing.. they need to use this HubAction constructor:
HubAction(String request, Protocol protocol)
documented here: HubAction Object - Hubitat Documentation

and Protocols are documented here: Protocol Object - Hubitat Documentation


Parent/Child device not actioning on/off
#8

Thanks. Added the second parameter to both. Also applied 2.1.4 update. Hub became responsive this morning and requires reboot. I updated my support ticket #14101


#9

FYI, fixing those HubAction calls eliminated my crashes and slowness. It’s been two weeks with no issues. Thanks again, @chuck.schwer!