I have mine on USB too - I can only imagine the cost of replacing all these batteries after all the initial testing iver had to do lol.
so a dual reports not a error, the log just sees both. No probs if thats the case.
@csteele is there any way I can stop these messages from getting in my logs? Besides editing the driver code myself?
Figured I'd post this here...just in case... Anyone else see something like this?
I've never seen the humidity fluxuate this much this quick. Bad device? Something that changed in the new HE version? Anyone else?
maybe.. this is from an event log:
humidity 51% 2019-10-01 11:42:26.859 AM PDT humidity 50% 2019-10-01 12:27:26.814 PM PDT humidity 60% 2019-10-01 12:47:26.797 PM PDT humidity 67% 2019-10-01 12:52:26.792 PM PDT humidity 73% 2019-10-01 12:57:26.784 PM PDT humidity 69% 2019-10-01 01:02:26.781 PM PDT humidity 67% 2019-10-01 01:07:26.773 PM PDT humidity 64% 2019-10-01 01:32:26.757 PM PDT humidity 63% 2019-10-01 01:37:26.754 PM PDT
Is anyone else also also having issues with the ultravioletindex?
Yes, my ultra-violet always measures 0.
Good point! Thanks.
I've used these for some time and the sunlight must strike the face of the sensor for UV to be detected. Naturally, any UV filtering in the way will negate that function. I first had one under an eave, for weather protection, near the front door and it never indicated any UV level simply aimed at the yard. If you place it in direct sunlight it will absolutely work but then you have it exposed to the sky and it is not weather proof. I have no use for the UV data so it's never been an issue for me.
1 Like
I installed the latest driver code some of my sensors report 10 degrees higher in temp then if I use the hubitat built in driver.?? If i switch back to built in driver they go back to reporting normal temps
I have quite a few and haven't seen that...
I opened a Live Logging tab then turned on debugging on one of the Multisensors. After clicking Save Preferences, there's a LOT of debugs... which is the Hub sending (simultaneously) about 20 commands to the Multisensor.. and then there's the wait for the Multisensor to respond.. But when it does respond, one of the results is:
dev:845 2020-06-05 02:15:13.947 pm info Temperature is 80.1°F dev:845 2020-06-05 02:15:13.944 pm debug finalval = 80.1 dev:845 2020-06-05 02:15:13.936 pm debug raw temp = 26.7 dev:845 2020-06-05 02:15:13.934 pm debug In multi level report cmd = SensorMultilevelReport(precision:1, scale:0, sensorType:1, sensorValue:[1, 11], size:2, scaledSensorValue:26.7)
26.7c is 80.06f -- which looks to me like a correct result.
I'll inspect the code, because the most recent change was dealing with the tempOffset per @christie999 However, a brief glance at the command that was affected by that change shows it to be correct/as expected too:
dev:845 2020-06-05 02:25:19.181 pm debug Sending Z-wave command: ConfigurationSet(configurationValue:[6, 2], defaultValue:false, parameterNumber:201, reserved11:0, size:2)
(configurationValue:[6, 2], <-- the 6 in that line is what would have been affected.. and 6 is what I put in for that field. But like I said, I'll recheck.
dev:14412020-06-05 02:42:13.034 pm debugfinalval = 74.3
dev:14412020-06-05 02:42:13.030 pm debugraw temp = 23.5
dev:14412020-06-05 02:42:13.027 pm debugIn multi level report cmd = SensorMultilevelReport(precision:1, scale:0, sensorType:1, sensorValue:[0, 235], size:2, scaledSensorValue:23.5)
Thanks for that info, Looks correct in my logs I'll give it some time because the temps are dropping towards normal but very slowly.
actually I'll switch one of the sensors back to built in driver and see if the temps go back to normal something weird is going on.
As promised, I looked at the code and although I didn't find anything related to temp, I did find two other questionable areas and I've attempted to fix them... along with what seems like a never ending need to 'beautify' the code with consistent indenting, etc. 
-
Clicking Save Preferences seems to have always been sending the set of parameters twice. That can't be right... it's pretty rare, unless like me, you're developing.
So I've reduced it to once per. -
Motion Detection (meaning a report arrived from the MS6 indicating Motion active or inactive) occurs twice. Once using what Aeon calls Notification: Home Security:
...and again via basicSet or via sensorBinary.
dev:845 2020-06-07 11:31:58.981 am info Motion is active by SensorBinaryReport dev:845 2020-06-07 11:31:56.062 am info Motion is active by NotificationReport
...don't need duplicates. I decided to 'clip' the NotificationReport and have it just deal with Acceleration and Tamper, allowing the SensorBinaryReport to facilitate Motion detection.
These changes don't do anything to/for the Device, they simply make the Logs look better 
I have 12 of these MultiSensor 6's and I'm going to test overnight to verify all the motion events I care about continue to occur.
If successful, I'll release the code as v1.7 tomorrow.
3 Likes
Released v1.7 per the statements above.
Logs now look like this:
dev:845 2020-06-08 07:13:55.953 am info Acceleration is inactive by NotificationReport dev:845 2020-06-08 07:13:55.951 am info Tamper cleared by NotificationReport dev:845 2020-06-08 07:13:55.716 am info Motion is inactive by SensorBinaryReport dev:845 2020-06-08 07:12:47.325 am info Motion is active by SensorBinaryReport
4 Likes
If you open a Live Log tab, and turn on debugging for a MultiSensor6, you should see a large set of debug output... including:
dev:845 2020-07-07 07:45:07.213 am debug Sending Z-wave command: BatteryGet() dev:845 2020-07-07 07:45:07.211 am debug Sending Z-wave command: ConfigurationSet(configurationValue:[0], defaultValue:false, parameterNumber:81, reserved11:0, size:1)
Parameter 81 is the LED Options command, and there are two permitted values: 0 and 1
"configurationValue:[0]" is where you'll see the value sent.. 0 in my example - which is:
Looks right.
I just set mine to Disable when Motion and in 2-3 mins I'll know if the LED is off always.
This came up a month ago.. perhaps in a different topic, but there's a tiny change needed.
I've updated the code, so I suggest simply re-import the driver code from github. (just click Import and save) [line 592 is fixed]
The LED discussion revolved around the fact that Aeon changed their mind. In versions prior to 1.10 there were only two states... on/off, but in v1.10 they added a 3rd: Disable when Motion
It meant the LED would come on for Tamper, etc, but not flash on motion. In v1.13 that option is gone again. My next version was going to include that fix as well as an option to always display the full set of parameters. I haven't finished that yet, but the tiny change for LED got left behind. Sorry for the miss. 
1 Like
Sorry guys, where can I find the latest version of this driver?
I can't set the reporting time period with the default driver.
Thanks
HPM, or
paste this to Import:
