Probably the final update. Jump to the last post as the intermediate posts helped solve the problem, however, the problem was caused by my bad Hubitat misconfiguration (not a coding error as initially expected).
So can somebody please suggest where I can start to debug the following error message? Would you suspect that it is my App code, or a driver/library issue? After further debug (see later logs), this error shows up in the Hubitat log, but it is actually a Konnected.io driver/app issue, that occurs while running a rule machine app (that I wrote) to drive Konnected hardware. This is not an RM issue.
dev:342022-11-21 01:09:18.948 pm errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_konnected_io_Konnected_Switch_580.setStatus() is applicable for argument types: (java.lang.String) values: [0] (method setStatus)
I am thinking that the only App that interacts with dev:34, K-Z08 HSM Armed SRL (Konnected alarm output that switches on a lamp) is:
Select Trigger Events (ANY will trigger)
HVS-K-Z08 Lamp Test(off) turns on
HSM status reports Armed Home
HSM status reports Armed Away
HSM status reports Armed Night
Select Actions for K-Z08 Armed Lamp ON/HSM Armed OR HVS-K-Z08_v1
On: K-Z08 HSM Armed SRL
Here is how you decipher that error. The error is coming from device:34 so that would be a driver, not app. Something is trying to call the "setStatus" function in that driver (possibly the app). It is trying to pass a string to the function, value of "[0]", but there is no definition of setStatus in the driver which accepts a String as an argument.
jtp10181
Well that's good news and bad news for me. Good news is that it's not something stupid that I am doing. The bad news is that the driver is from Konnected ... so I won't be fixing it.
My guess is they are probably meaning to send a list with a single element of 0, which would be [0] in the code, but are instead either sending "[0]" directly (in quotes as a string), or a String variable that contains that.
After contacting Konnect multiple times, and continuing debug with them, the Konnected.io driver/app appears to be the issue. Hopefully we will get an update in the new year (2023) ... but no guarantees were offered.
I am running a 2-board, 12-zone system (6-zones per board). I also tested moving the output from the second board (Zone 10) to the first board Zone 5). The same error appeared for the newly assigned Zone 5 output.
This error shows up as the Konnected.io output being switched OFF (uncommanded) while Hubitat stills sees the output as ON. Additionally, this error (for me) propagated to the Chirp output which goes off after two minutes, and then turns back on after another minute ... and restarts the ON/OFF cycle again.
With the "black-box" debug method that I am using, this is as close as I can get to an explanation of the problem.
Is this is "user" driver or built in? If its a self-installed driver give me a link to the code, I could probably figure out a patch in a few minutes to get you going.
Can you turn on debug logging in the app and then so whatever it is that makes that error. Get a SCREENSHOT of the debug logs leading up to and after the error (if any after). Hopefully that will show me the route this code is taking leading up the error, it is sort of hard to follow.
OMG ... Thanks for the offer to fix the code. I thought that you would probably find the code ... which saves me from having a heart attack ... because the code is not mine ... and I am just "black box" debugging. I haven't coded in many years.
If you can tell me how to email you, I will send you the email trail I sent to Konnected.io support.
Otherwise, here is a (screen to text) debug log showing the error.
app:67 2022-11-26 02:09:41.721 PM warn Alert Intrusion-Home canceled dev:43 2022-11-26 02:09:28.360 PM info K-Z03 Nook is closed dev:38 2022-11-26 02:09:18.130 PM info K-Z12 Garage Door is closed dev:37 2022-11-26 02:09:17.807 PM info K-Z11 Contact Sensor is closed dev:36 2022-11-26 02:09:17.486 PM info K-Z10 Contact Sensor is open dev:35 2022-11-26 02:09:17.168 PM info K-Z09 Contact Sensor is open dev:34 2022-11-26 02:09:16.845 PM errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_konnected_io_Konnected_Switch_580.setStatus() is applicable for argument types: (java.lang.String) values: [0] (method setStatus) dev:47 2022-11-26 02:09:07.476 PM info K-Z00 Siren SD 20W is on app:67 2022-11-26 02:09:07.103 PM warn Alert Intrusion-Home K-Z03 Nook open dev:47 2022-11-26 02:08:07.360 PM info K-Z00 Siren SD 20W is on app:67 2022-11-26 02:08:06.992 PM warn Alert Intrusion-Home K-Z03 Nook open dev:47 2022-11-26 02:07:07.261 PM info K-Z00 Siren SD 20W is on app:67 2022-11-26 02:07:06.885 PM warn Alert Intrusion-Home K-Z03 Nook open dev:43 2022-11-26 02:07:06.836 PM info K-Z03 Nook is open dev:34 2022-11-26 02:06:13.027 PM errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_konnected_io_Konnected_Switch_580.setStatus() is applicable for argument types: (java.lang.String) values: [1] (method setStatus) dev:34 2022-11-26 02:06:12.943 PM debug K-Z08 HSM Armed SRL is on dev:34 2022-11-26 02:06:12.603 PM debug Turning on K-Z08 HSM Armed SRL (state = 1) app:67 2022-11-26 02:06:12.292 PM info Armed Home
Easy, peasy. Just switching the output on causes the bug. I am guessing that most (normal) people don't have the logs running and so they don't see the bug ... which is why it hasn't been reported.
I wasn't really worried about it until it started causing anomalies in HSM operations.
Here is a simple HSM alarm, intrusion, disarm sequence. Dev:34 is the Konnected.IO output.
Looks like you turned on debug logging in the device itself, can you also turn it on in the APP? Looks like it should be under advanced settings.
It does look like it is changing the device state despite the error, but maybe not always. Please confirm what is device 34 exactly (make and model)? It looks like it is using the "Konnected Switch" driver (listed as type on device page). EDIT: Also please tell me the "Device Network Id" listed for this device on the device page.
I am starting to lean towards it being some sort of configuration issue. The code looks very good I would be surprised if they left such a blatant issue in there where the setStatus function is totally missing from the switch driver. I am guessing there is some setting that is causing it to think the device is something other than what driver it is using.
BTW I love tracking down a good mystery, especially in code.
OK ... Understanding that I am not sure what I am doing ...
After I did everything and got the logs ... I disabled the debug and Hubitat/the boards reset (or I hit reset ... but I didn't see any reset ... it normally takes like 20-seconds). The reset seems to have invalidated my code!!! I am assessing damage now. I am not posting the logs because I don't know when I lost the boards. Posting the revised logs will probably need to wait a bit while I restore/rebuild ...
So ignore the following ...
I enabled debugging on the following:
Konnected App (app:65)
Konnected board 1
Konnected board 2 (app:66)
I Armed Home and Disarmed.
Notes:
app:66 pin 8 is the arming chirp (my code)
app:101 is the Armed lamp K-Z08 (Konnected-Zone 08) output
The "No signature" error isn't showing???
But ... app:100 is my RM code is driving K-Z08 ... and it is throwing an error
So here's what I think is happening to cause my Hubitat setup to implode after putting Konnected into debug mode. Reiterating .. I am still working "black box" debug, so I am not clear on exactly what is going on, so these are my opinions, backed up by observation, but not firm facts.
BLUF ... Unless you can think of another way around this ... Although probably only a few hours work to "totally" reprogram the system, I don't currently have the time ... so unfortunately, even though I need a fix, I think that we need to abandon the debug effort for now. I will continue to develop a workaround.
Here is some backup material:
The Konnected app shows the following I/O names (just showing two):
Whereas Hubitat Devices (for the same I/O) reconfigures the I/O as follows:
What I (think) that I saw yesterday, after my system started throwing errors like there was no tomorrow, is ...
I switched to Konnected debug mode
All of the Konnected I/O names changed to the Konnected I/O app names (not the Hubitat names)
I presume Hubitat went WTH? and invalidated the I/O
So my Hubitat App code indicated that it could no longer find the I/O causing the app:100 errors above
So to actually go into Konnected debug mode, it appears that I would need to run a rebuid a "test" rig where I would:
Engage Konnected debug
Reset the I/O devices needed
Rebuild the APP code
Reset HSM to use the "new" devices
See if I could reproduce the error again
I would think that the Konnected people, when debugging, probably do use a "basic" setup and change it minimally to save time. That doesn't appear to be useful if the Hubitat system is already configured.
I see in the top screenshot you are showing one Switch and Open/Close sensor. In the second screenshot both devices have the Switch driver. That is probably what is causing your errors. The two drivers work differently, so if in one place it thinks it is an open/close sensor but the switch driver is assigned it cannot communicate with it correctly.
If it really is an open/close sensor, change the driver on the hubitat child device to the matching driver, or if its a switch change the type on Konnected. As long as they match I suspect you wont get errors anymore.
The fact that it goes haywire when debug logging is turned on tells me something must be way out of sync from Konnected to Hubitat. It is probably trying to sync back up and re-creating all the childs so they match the Konnected configuration would be my guess. Not sure how to get it back in sync without blowing it all up, possibly getting the type and drivers to match will keep it happy.
Thanks jtp10181 for your dogged follow-up and relentless problem solving.
The problem was caused by my bad Hubitat misconfiguration (not a coding error as initially expected). This was brought to my attention by jtp10181 ... "I see in the top screenshot you are showing one Switch and Open/Close sensor. In the second screenshot both devices have the Switch driver. That is probably what is causing your errors".
Basically speaking, I thought that the Hubitat/Devices I/O settings were "overriding" the Konnected App I/O settings. The specific switch output was turning on and off as expected. However, the fact that I had Hubitat specifying an I/O as an OUTPUT, but my Konnected APP thought it was an INPUT ... apparently caused the "No signature of method" errors to be thrown (no surprises there!). Those errors interfered with the Konnected boards operations significantly ... causing me some consternation.
Today, I 1) reset the I/O configuration in the Konnected App and then 2) moved to Hubitat/Devices to refine some of the settings. Now I think the Konnected App settings take priority. So, I will be changing the I/O settings in Konnected App in future (not Hubitat). There have been no errors since.
One of the "flags" that started us down the path to the solution was that jtp10181 asked for the debug settings be turned on in the Konnected App. Due to the differences (Hubitat vs Konnected) when I turned on debug, Konnected updated the Hubitat I/O settings, and that invalidated a lot of my code that used that I/O. A Hubitat restore saved me on that ... but I still need to redo the Konnected configuration and update my apps after my configuration error was found. So if you are running Konnected debug and your Apps and I/O gets invalidated, chances are the configuration was wrong in Hubitat.
Good news is that it's not something stupid that I am doing. The bad news is that the driver is from Konnected ... so I won't be fixing it.
