I will let you know on Sunday what I find. If it resets to 0", that will solidify the theory. I'm pretty sure that is the way it works, though, because we got 0.59" of rain on Saturday but the weekly rain value shows 0.02", which is the only rain we have gotten this calendar week.
I went ahead and created a rule for a rolling 7-day total just in case.
Since you are querying the site, additional sensors appear, I also do not need to link it when using Hub Mesh either. I have additional temperature sensors, and their solar powered particle monitor.
Besides being two months old, the post you replied to is the driver author's post, so I suspect he knows. It may be helpful if you quote the posts you reply to (perhaps this wasn't supposed to be his? Discourse does show it as the replied-to post, at least), consider combining multiple posts into one (you can do this and still quote each other post individually), and evaluate whether older posts might still warrant a reply.
@jeff.lilliquist: Little clarification based on a couple things I saw in there:
Yes, child devices are created if the Enable Child Devices preference is on. I recommend it because it makes it much easier for people to handle things like temperature or such if they have multiple sensors. Even the indoor/outdoor portions of a basic package usually both report temperature and humidity at least.
There is no app associated with my driver set (this thread). This one is also not listed in HPM. Some of my drivers are, but this one is not. So you may be referencing a different person's driver.
Thank you for confirming about the "Weekly" rain for us. It would be nice if they put that in their API/local data descriptions, but now we know. I think I will add a comment about these types of things being CALENDAR weeks/months, rather than # of days, in the driver for the next time I update it.
First, thanks for all the work on the drivers that support the AmbientWeather station. I have both the AmbientEcowittWeather v0.7.19 and the WeatherSensorChild v0.8.4 loaded. However, when I save the html in the WeatherSensorChild as shown (note - I've escaped all the special characters here to have them display properly):
<p>Temperature: ${ temperature }°F</p><p>Humidity: ${ humidity }%</p>
all the tags get stripped out, resulting in:
Temperature: ${ temperature }°FHumidity: ${ humidity }%
The added tile works, but all the data is concatenated together.
It is working as expected at this moment unfortunately. Hubitat introduced a security fix a couple versions ago that strips HTML tags out of things exactly like this. I have not gotten around to updating all my drivers with the workaround I came up with, and this is one of them.
But... now that I am reminded of it, I should have an update later this evening.
As a note, besides escaping them you could use the [code] ... [/code] tags around it as an alternative.
<p>Temperature: ${ temperature }°F</p><p>Humidity: ${ humidity }%</p>
In any case, once I make the change it would be almost exactly the same except the <> are replaced with [], so it would look like:
[p]Temperature: ${ temperature }°F[/p][p]Humidity: ${ humidity }%[/p]
So if you want to "future proof" it and do not mind the extra stuff that will show in there before my update, you could always use that. Or just hold off until the update is published and then use it.
Thanks for the quick reply. For the record, I escaped the example in the message here so that it would show the angles on the tags. "Escaping" the angle brackets in the template doesn't work either. I will hang tight and look forward to the update.
Ok, got the changes in earlier than expected because I was able to copy it directly from newer drivers. There are a bunch of other changes as well, so read over please:
Updated Version(s):
WeatherSensorChild.groovy = 0.8.5
Change(s):
Changed to a new method to replace the no-longer-functional htmlTemplate. You will have to set it all over again and Save Preferences. The new attribute is called "Tile". It functions the same as the previous one but < > characters should be replaced with [ ]. It should handle all standard HTML commands if you remember to use the [ ] instead.
Removed the Clear command. Not much value in removing all the current state data outside of testing purposes.
Update to the Logging method, both the Preference structure and how it actually gets implemented. This driver had not been updated yet in 2022 (and not sure when in 2021 it last was) but it was not using my "latest" method of Logging.
Update to the driver update check mechanism. Some cleanup and bringing it in line with my "current" methods of performing this.
Just to clarify (noob to this driver and still noobish to HE as a whole), this driver does not automatically convert "device attributes" into hub or rule variables, correct? I need to manually set them to variables myself? Not complaining about having to do that, just wanting to make sure I am not re-doing something that has already been done.
Nope. I do not know of a way for a driver to set a Hubitat variable. That does not mean there is NOT one (things keep getting added and improved on) but if there is, I do not know it.
But the items listed in the driver as attributes can be used in most places by the Hubitat, so your rule & variable method should be fine.
Your browser may have the older version cached. All this is stored on a website, so their trying to be "helpful" can actually botch this up (even if using the Import from the Hubitat). Easiest method is to go to the driver page (from the link) and refresh it. Then you can check the version listing in it to make sure before you copy/paste or use the Import.
If you are looking at just the status message in the Events, that will only get updated on the next time it does the daily update check (per the scheduled tasks). But if you Save Preferences it will update the State Variable that says "Driver Version". That should be 0.8.5.
Awesome - thank you so much. Didn't occur to me that it was cached. Got 0.8.5 now. Gonna go give it a whirl.
[UPDATE] - Trying to get the old driver to work, I've probably messed something up. Once I loaded the new WeatherSensorChild v0.8.5, the child devices both the attribute lists revert back to the individual fields under the attribute. "Tile" is not listed and the older "html" is gone too.
I got around that by saving the preferences and then refreshing the page. Then, the "Tile" value is set. Once that is there, I can now see "Tile" on the attribute drop down.
However, if I try to change the value in the Tile Template (save and refresh) the Tile value in the upper right never updates. Then I had an aha moment. The Tile value refreshed while I was typing this message.
FYI for others the Tile Template once saved is constrained by the refresh on the parent device - which you can refresh manually.