after the first run populating the state variable which i put a map/hasmap in appears fine but the get operator is never finding anything in it.. if in turn i put a new element in it that is found fine..
any ideas..
ie
Are you sure it's not a String? You can do something like this to see, though it will be quite verbose for a large list:
globalDeviceType.each { k, v ->
log.debug "key $k of type ${getObjectClassName(k)} = $v"
}
Or you can try .get("301") instead to see if that makes any difference. That would be my first guess -- it's a common cause of unexpected results finding map keys.
Also, keep in mind that your globalDeviceType variable is going to be reinitialized on every execution of your driver code. If you want it to persist between executions, you'll need it to be static. This is far more common, though using state directly could alos make sense -- it's not written until your driver code exits, so I'm not sure what problem you might have been trying to solve but passing between the two could also be causing some oddity. Keep in mind that in all cases (though in the former it probably won't matter, and in this particular driver is probably what you want -- though in many drivers it is not, another advantage of state), this variable value is shared among all instances, not just any particular installed device instance.
2 Likes
thats the issue but the first time thorugh it is found using an int and and on subsequent calls it is found using a string.. see the two fxs below the test loads the table into the state variable
and test2. just uses it..
and the erroneous results.
guess i can write code in the search fx to try both ways before giving up that is so stupid though
So you're reading it once, letting the app go back to sleep, and reading it on the next wake? That could explain it. The map is persisted to JSON on exit and reconstructed on wake, every time, so the exact data type may change (but shouldn't after the first time unless the data itself changes). Apparently your embedded keys are reconstructed as strings, even though they are numbers when you manipulate them directly before persistence, likely how the JSON parser works, as JSON keys are always strings per JSON specs.
To avoid this, you could force them to strings from the get-go, for example by replacing your line 46 with something like this:
globalDeviceType.put(id.toString(), type)
ya let me try that i did this kludge instead which does work lol
the whole point of this is that getting each devices type is a endpoint call and with doing it every time takes 26 seconds to run vs.. 1 sec.
worse issues now look at this code and output it works fine for awhile then goes nuts i dont know if i have bad memory in the hub or what..
ie
i think it is doing all the processing correctly but the logging is just wonky and there is a missing semaphore or something and it is getting out of order... thoughts?
yep i put spot checks on just certain ids that looked wrong in the output and they come out fine so it is just the debugging output getting out of order..
there is definately a semphore or something in the hub os missing to keep the output in correct order.!!
@support
@gopher.ny any idea on the debugging content out of order?
Maps aren't an ordered structure.
thats not the point did you look at the output.. doesnt matter what order i enumerated through the map the debug output is out of order it shouldnt output the next map element till the followng 2 lines are output.
OK, does this really matter?
Yes...
Hard to debug code if you cant rely on the output order.
Functionally probably no... i was able to verify correct function by hard coding checks/debugging output for just a few ids and verifying.
