You are very welcome!
I have been using AP as a means to test Follow Me (by setting up humidity averaging and a target that I know the home average will always be below). After the recent update I noticed I wasn't getting any speech:
I took a look at the app code for the child, and I think I found a couple items you may want to look at.
- In both the lowSetpoint and highSetpoint subsections of averageHandler (lines 423-428 and 450-455), the processing of state.theMsg and use of messageHandler to substitute the actual value for the placeholder of %avg% happens inside if statements for pushing the message as text. If the notification preference chosen is only spoken through Follow Me, then those preparatory steps never happen. It seems like maybe those should both be outside the push, so they happen regardless of the type of notification (or so that a user doesn't have to use both for speech to work).
- The other item that caught my eye was for the high setpoint section that I wasn't using. Instead of state.theMsg being set in that part, it said messageHandler = spHighMessage, and then the variable messageHandler (not the method) didn't seem to be used anywhere else.
I tried moving the variable setting outside like this (and simplifying the if statement):
state.theMsg = spLowMessage
messageHandler()
if(pushMessage && !state.sentPush) pushNow()
if(useSpeech && fmSpeaker) letsTalk()
}
and repeating my test led to it speaking, and this log
I can't remember if I had already looked at this about a month ago, when I first started using Follow Me, and had neglected to bring it up then. So it's totally possible this section of the coding had nothing to do with what you were updating. Just that the new version in HPM restored this section.
Incidentally, if someone could explain GitHub to me - I don't mind figuring out how to submit possible coding suggestions there instead of this message board or via DMs. I just haven't figured out how I can do that, yet.
attrib enum illuminance
errorjava.lang.NullPointerException: Cannot get property 'supportedAttributes' on null object on line 126 (method pageConfig)
Should work right?
Mind you I need to update the version I'm using. But I'm just asking as I do that.
Go ahead and update to the latest, then show me a screenshot of the debug log.
thanks
Ah, duh! I clicked on the ONE, and ONLY, device that reads illuminance...like how's that gonna AVERAGE without another device.
I took you literally
But wait, perhaps there's an idea...a "next gen" capability ? Averaging just ONE device.
What I was looking to do was get THE AVERAGE reading off that device during particular time windows. Admittedly I didn't expect your app to allow me to set them, ...I was just gonna watch the average.
For-
a) the ambient level during post dusk nighttime (e.g. night level average over time to arrive at an average luminescence level from the combination of overcast nights that reflect area light AND clear sky nights with near total darkness) [Aside: I want to use this as a threshold for triggering actions when lux levels exceed "the average". Ideally this would be an ongoing average, for the last hour say, but I'd be happy just to get "a fixed empirical or representative number" for a typical night time level.]
b) mid-morning to mid-afternoon ambient to get an average lumen level for an overcast summer day
c) mid-morning to mid-afternoon ambient to get an average lumen level for a clear summer day
Yeah, I know, I know...."there's RM and Variables, go have at it"
Ha! Not from me. I don't use RM at all.
New version on GitHub...
1.2.0 - 02/26/22 - Added option to average a certain device over time, also added time between restriction.
GET OUTTA TOWN ! You're somethin else !
Thanks!
OK, this has to be something simple.
errorjava.lang.NullPointerException: Cannot get property 'supportedAttributes' on null object on line 125 (method pageConfig)
Here's the night value currently reading off the device. Admittedly this lower than I expected...so yeah, we may be averaging ZERO at night... but still...
Not sure the purpose between the two differently named values, but we can ask @birdslikewires
This would have been fixed yesterday, BUT I'm still waiting on a Debug Log.
One has the Unit included (lux) and one doesn't. The one with the unit is great for displaying on a dashboard. But when doing any kind of calculation, you would need to use the one without the unit.
New version available...
1.2.1 - 02/27/22 - Adding 'reference' device for Delta
Whoops!
1.2.2 - 02/27/22 - Fixed a typo
Whoops, sorry....forgot.
OK, here's what's up ....and I'm not sure what of this you want to, or should, bother building in for idiot proofing.
This was all USER ERROR in following the configuration/menu form steps. Namely around setting up the Virtual Device and rushing around the form instead of following down the process. Basically FORGOT how to run through/set these up.
It worked after I removed and went back through it from scratch. I was having some issues with being sent back to complete fields I had thought I had completed.
Seperate Question: So Children that have been created off old versions just stand on their own and there is no reason to mess with (delete and recreate) them unless I need updated capability in those....right?
New version available...
1.2.3 - 02/27/22 - I got carried away, major rewrite!
Check your child apps!
OK, it took me another look to see what ALL you've done here. Quite a capability expansion and hitting all the marks.
So I started out thinking I'd take the average and compare it to the reference with the reference being the Lux device. Then realized that you actually allowed a comparison of incoming data to the most current average (might wish that was swapable to one of your other duration averages, i.e. week Ave, etc.) So now I'm wondering how to disable the menu pick for the Reference comparison.
EDIT: Thanks for the reply to this. Un-select; of course! I was looking for a "blank" at the top of the menu stack to select to undo my select.
To change up options, simply unselect anything you don't want to use. The other options will pop back up.
Nailed it.
errorjava.lang.ArithmeticException: Division undefined on line 446 (method averageHandler)
I'm surprised by the sensor reading ZERO lux...but it is, and will likely stay the same till morning twilight. I would have thought it would have never been less than 1 where I have it. Might this be causing a divide by zero situation for your code?
Yup, that's the issue. Let me put on my thinking cap for a bit.
Or should I ask @birdslikewires if he thinks it would server multiple purposes to put an Offset/Correction setting in his driver so that, for example, I could put in "1" and the device would never give a reading lower ? Thus no divide by "0" encountered.
That's not likely a good long term solution on your end because you couldn't be sure of what any driver/device might feed your app.
Was thinking more on the, 'if value == 0, then value = 0.00000000001'. That way the value isn't skewed too much but avoids the div by 0 problem.
New version available...
1.2.4 - 02/28/22 - Fix for div by zero error