Can't you just do a wipe states command when you call the "updated" then it will wipe what was there before and renew what has now been saved.
I have a driver that only does clean state and clear schedule for stuff like this, but if this was called at the correct time it would do both? Or am I thinking of something else 
From post #31:
ATTRIBUTES CAUTION
The way the 'optional' attributes work:
- Initially, only the optional attributes selected will show under 'Current States' and will be available in dashboards.
- Once an attribute has been selected it too will show under 'Current States' and be available in dashboards.
<*** HOWEVER ***> If you ever de-select the optional attribute, it will still show under 'Current States' and will still show as an attribute for dashboards BUT IT'S DATA WILL NO LONGER BE REFRESHED WITH DATA POLLS . This means what is shown on the 'Current States' and dashboard tiles for de-selected attributes may not be current valid data. - To my knowledge, the only way to remove the de-selected attribute from 'Current States' and not show it as available in the dashboard is to delete the virtual device and create a new one AND DO NOT SELECT the attribute you do not want to show.
I wish there was a better solution ..... but I have not been able to find it. If anyone has ideas ..... please share.
My overly simplified (and technically inaccurate) explanation of this:
- You must declare an attribute in order for it to be available outside of the driver itself (e.q for use in dashboards or in Rule Machine).
- If you declare an attribute, the only way to remove it from the 'Current States' is to delete the virtual driver and create a new one where that attribute has never been declared. You can stop updating the attribute, but you cannot remove it. This is a platform functionality issue and is not specific to this driver.
- It is possible to have an attribute that is not declared. That undeclared attribute can be 'wiped' so it will no longer show in the 'Current States. However, since it has not been declared, it will not be available outside of the driver (e.q for use in dashboards or in Rule Machine).
- This driver uses 'data' elements for internal driver variable use. By using 'data' instead of 'states' it does not store these values in the database and does not keep a record of the last 5,000 values in the database like 'states' does. This prevents the driver from using hub resources and can greatly reduce the burden on the hub versus using 'states.' Any value polled from DarkSky is put into a 'data' variable and used as required in the driver. Only the minimum required variables and those selected by the user as 'Optional Attributes' are put into 'states.' That will make them available outside of the driver. The more attributes that are selected as 'states', the more hub resources this driver will take. The user has control of what they want to do here.
To my knowledge the inability to remove/delete/clear/wipe attributes that are no longer desired is a platform limitation that no one has been able to overcome programatically. I do hope that someday the platform will be altered to allow this, or someone figures out how to do this with programming. I and many others have tried and have not succeeded. Hope you have better skills and luck, and please share how you did it if you do succeed.
Thanks.
1 Like
The hub watchdog driver has a clear data button, could that (code snippet) be used to 'null' the values to remove confusion?
'null'ing the values is not the problem or the issue. That may help with some confusion by the uniformed, but really does not change anything as far as driver utility or hub resource utilization.
If an optional attribute was on and you turn it off it will still show, but will not update. That does not get rid of the existing 5,000 prior database entries that will continue to be backed-up and restored and use hub resources. They should no longer create new database entries, but this is no different whether they are 'null'ed or retain their last polled value, so no saving in hub resources here.
In order to determine if an optional attribute was on and was turned off, I believe you would need to create yet another declared attribute to hold the current value (on or off) of each optional attribute. If this is true, you are actually contributing to the problem and making it worse by trying to make it better. In my opinion, the benefit of preventing confusion of users that have not read the thread/instructions on the issues around unused optional attributes does not justify the additional resources required to prevent that confusion. My current solution is far less elegant ... read the thread and the instructions to understand the known issues of the driver you are choosing to use. I am opposed to making the driver less efficient for everyone to benefit the minority who do not read the thread/instructions and understand the fundamental issues which they could have avoided if they did.
I do not intent to sound critical of anyone's ideas or contributions. In fact quite the opposite. If a benefit can be implemented at little to no cost, I am all for that. On this subject ... I have not seen a solution that did not have a cost that exceeded the benefit (in my opinion, YMMV). There have been a few confused users (including myself when I first ran into this issue). But in the 284 posts so far in this thread ... only 3 or 4 were started because of this confusion (granted those generated 10's of responses). Still the information to understand and avoid the issue is addressed in the instructions. Users just need to put forth the effort to read that. Could I add programming and create more hub resource utilization to potentially prevent some confusion ... YES. Will I ... NO. I prefer to continue to point the confused who have not read the basic instructions back to those instructions to help them understand the issue.
The beauty of open source is that if anyone does not like this solution .... well... they are free to take the current driver code and create their own variant of that to accomplish what they would like to do.
Thanks.
4 Likes
Is there anything that would have changed in 1.2.8 or 1.2.9 that would stop Darksky from showing up in Sharptools.IO....The other night I upgraded from 1.2.7 to 1.2.9 -- and I updated my HUB to 2.1.8...Now Darksky does not show up in my Sharptools "Things"...It has been authorized both in the Sharptools HE App, and within SHarptools page...I have the Sharptools attribute setting turned on in the device settings.
Before I start rolling back versions - has anyone else seen this?
Thanks,
Mark
We've found that when a device reports a large number of capabilities / attributes in its definition, but it doesn't have data populated in the states for those attributes that it can sometimes bog the hub (or relay?) down when the system is trying to sync over devices. This has been accentuated for some people lately who have been experiencing general hub slow downs.
As a workaround, @Matthew graciously gave me permission to post a stripped down version of his amazing driver which includes just the attributes that SharpTools needs. You can find more details here:
3 Likes
This worked - THANK YOU!!!
1 Like
Newbie here... how might I pass the weatherSumary text output value off to TTS? I've set up MediaRenderer Connect, and have it working otherwise. I'm just a little unsure how I pass a value from a different app? I just wanted to have a scheduled weather summary announcement over my speakers. Thanks for any help.
-Ryan
I have not done it, but is a been done. Look in this thead around Sepember 2019 for that discussion.
Just set up a rule to stick the weatherSummary parameter into a global variable (I poll the service and re-store this parameter every morning at 6 am), then use %weatherSummary% in your TTS notification text. It works very nicely. I had some problems with the Darksky attribution also being read out but there is now an option in the driver to remove that. I have a weather forecast read out to me every morning by a Google Home device when I come down the stairs and activate a motion sensor. And depending on who it is coming down the stairs (based on the Withings bed pressure pad reading), my wife also gets an additional message to bring me breakfast in bed lol.
2 Likes
Thanks, that helped. I was able to get it set up.
@Matthew Is there any change you could add a line spacing option in the MyTile tile. Now if I may the font larger for this tile the line spacing gets larger too.
Not easily. There is already a lot of formatting in the myTile block and it all uses up the limited characters available in the dashboard tile. Adding additional formatting options will further reduced the data that can be displayed. As it is now, the line spacing should be proportional to the font size, so the larger the font size selected, the larger the gap there will be between the lines (but the actual line-spacing will remain proportionally consistent with the font size). I believe line-spacing is in relation to the font-size so a line-spacing of 1.5 for a 16 point font would be equal to 24 points (16 x 1.5) and a line-spacing of 1.5 for a 8 point font would be equal to 12 points (8 x 1.5). This is consistent with what you are saying that the the larger the font, the bigger the gap, although in reality the 'line-spacing' of 1.5 has not changed. To make the line spacing independent of the font size may create more issues than it resolves (overlapping text).
No one else has raised this as an issue before and I don't know how to accomplish this easily. I will think about how I may implement this .... but do not anticipate making this type of a change anytime soon.
Thanks @Matthew, the top 3 lines I was able to edit somewhat with a CSS edit....
#tile-10 div.tile-primary {
font-size: 23px !important;
line-height: 15pt;
}
The bottom 3 lines is what I was having problems finding a CSS edit that worked, any CSS would do what you stated above with the font to line spacing relation.
Does the Hubitat stand-alone dashboard have the capability to display other attributes from the DarkSky Device Driver. I selected the 3-day forecast and moon phase toggles under preferences but don't see them on the dashboard. I tried expanding the tile size but that didn't work either. Whats the best was to display the attributes on the Hubitat Dashboard?
[UPDATED]
V1.3.0
02/23/2020
*[****WARNING ***] It has been reported that there are some issues with this update. I suggest you do not update until I release a corrected version.
As requested by several users, added the ability to select the number of decimals shown. There are two groups i) Temperature, Wind Speed & Distance, ii) Pressure. Each can be set indepently of the other. You may choose to display from none (0) to four (4) decimal places, although I am not certain any data sources provide that level of detail.
1 Like
How can I trigger a weather alert rule?
Start here: Rule Machine - Hubitat Documentation
As described in that documentation, this driver exposes attributes that may be used as triggers for action(s). Make sure you turn 'on' any optional attributes you want to use as triggers or they will not be available to Rule Machine or dashbards.
