Wx "Placeholder" Problem

I’d had so many problems with Wx on SharpTools that I’m tempted to remove it permanently and stick my head out the window instead.

The following situation happens almost daily; at least a couple of times a week: Wx tiles come up as Placeholders. Observing it on Hubitat gives no indication of a problem. If I try to add Wx to a dashboard it’s not found in the “things” list. If you go to the account, it shows up in Hubitat’s list of devices. Authorizing it again doesn’t seem to help. The only way I’ve been able to get it back to life is to remove the SharpTools App from Hubitat and then add it back.

Suggestions for a permanent fix are welcome. Otherwise I do think I"ll remove it from dashboards.

Stan-
Thanks for posting and sorry to hear that weather devices have been causing trouble!

Which weather driver are you currently using? We’ve had a few other reports of community developed weather devices in Hubitat causing trouble and not consistently syncing over.

We’ve modified Matthew’s amazing DarkSky driver to improve reliability with SharpTools and the Hubitat Cloud Relay. You can find the modified driver here:

Simplified version of Matthew's driver - ALL CREDIT TO MATHEW - this is just a fix for quirks in Hubitat with missing defined attributes · GitHub

Considering that the existing weather device may be reporting excess attributes, I would recommend creating a brand new device with this driver, then authorize the new device in SharpTools and update your dashboards accordingly (and deauthorize or delete previous weather devices as needed).

A bit of background if you’re interested…

View Background Details

One of the challenges with the Apixu and Dark Sky drivers available on the Hubitat community is they are trying to cater to such a wide audience that they sometimes can cause issues with Hubitat’s Cloud Relay.

Specifically, when SharpTools asks Hubitat for the list of devices that you have authorized and their current state, sometimes these community developed weather drivers can cause issues on the hub or with Hubitat’s Cloud Relay. Several things can contribute to issues on the hub/relay including sending across too much data, reporting that a capability is supported, but not reporting the relevant attributes, and more.

Many of these custom weather drivers have been modified to try to meet so many people’s needs that they’ve started running into limits of the system. Some of these modifications include reporting all sorts of additional esoteric data elements and dynamically reporting attributes (even though the capabilities are static which causes an issue!)

We started seeing more reports of issues with custom weather drivers on Hubitat, so we stripped down Matthew’s amazing DarkSky driver to create a simplified version that only reports the attributes and capabilities needed for SharpTools. We’ve had a small number of people try out this driver and it has resolved the issues for them.

3 Likes

Thanks Josh - I’ll take a look at this material and see if I can figure out how to switch to Matthew’s driver. You say to create a device: I assume that would be a virtual weather device?

I’m now using Hubitat’s built-in driver. I started using it when word came out that the Weather Underground API would be deprecated.

Update: I’ve installed the driver, but don’t know how to associate it with a device. I hope it’s not something you’ve shown me before…

Stan-
Thanks for the additional details. I haven’t heard any reports of issues with the built-in OpenWeather driver, but I also don’t know if most people are using it with SharpTools since it wouldn’t expose a proper weather tile.

Regarding the installation of the Simplified Dark Sky driver, you’ll also need a free DarkSky API key. Since you already have the driver installed, the next step is to create the device:

  1. Open your Hubitat Admin UI
  2. Open the Devices page from the left navigation pane
  3. Tap the Add Virtual Device button at the top of the screen
    image
  4. Enter a name for the device (eg. “Weather”) and select 'DarkSky.net Simplified Weather Driver' for the Type, then press Save Device
  5. After you are redirected to the device screen, enter your DarkSky API Key, enter a valid City name, then scroll down and press Save preferences.

    You can get a free Dark Sky API key here: How Dark Sky users can use the Apple Weather app - Apple Support

After saving the preferences with a valid API key and city name, the device should pull in the weather conditions. Once that’s done, you should be good to authorize the device in SharpTools.io :smiley:

3 Likes

Look’s grand!

I’ll leave a temperature-only tile in place for a while to make sure that the problem I was having doesn’t originate elsewhere.

Thanks for the help!

1 Like

Thanks again Josh - This worked great for me! Hope it also fixes my hub slowing down :slight_smile:

Mark

@josh

Wow, thank you, I’m really glad I found this thread! I’ve been struggling for the past few weeks with slowdowns on my Hubitat hub along with frequent placeholders showing up on my Sharptools dashboards. I recently figured out the source of the issue was coming from WX data I was passing from Hubitat to SharpTools…

This thread confirmed the culprit was caused by me using the Weather-Display With DarkSky.net Forecast Driver by @Matthew, specifically, using that device in SharpTools. I agree it’s an amazing piece of code and I will continue to rely on it for rules/automations in Hubitat because it uses near real-time data from my backyard weather station.

However, for my SharpTools dashboards I’m now using this modified, simplified Dark Sky version for passing WX data. Thanks for sharing this, everything is running so much better!

1 Like

Hi @josh
I am experiencing a similar and very annoying phenomenon.

2 of my Fibaro FGS-223 modules (2 switches module) - got messed up.
A tile that was created to control one of the switches - turned to be “place holder” on dashboard, and handler on ST IDE was set to “PlaceHolder” without ability to change back.

On the 1st FGS-223 module, the only way to solve it was to delete it, open the electric socket and add it back on ST. IDE.

I now figured out it happened another time for another Fibaro FGS 223.
I really want to avoid opening another electric sockets in wall to solve it and afraid this is a severe bug that needs to be addressed ASAP … :cold_sweat:

@Roy_Kfir thanks for the message and sorry to hear that you experienced this.

If this happens again would you mind sending a note to support@sharptools.io so we can gather more details? The issue that was occurring in this thread was an issue limited to Hubitat custom weather devices that can cause issues with the Hubitat sync process.

If the device changed in the SmartThings IDE, that’s outside the control of SharpTools and would likely indicate an upstream issue - perhaps with SmartThings.

A placeholder tile in SharpTools should only occur if the device somehow becomes unauthorized (eg. unchecking it when proceeding through the authorization flow again). It sounds like it’s possible that this occurred as a result of whatever issue occurred within SmartThings for this particular device.

Hi @josh,
It might not related to SmartTools, yet - the “placeholder” text somehow brought me to think it is related.
Maybe I am wrong.

Understandable. :slight_smile:

We’ve been thinking about adding a ‘More Info’ type of link to the placeholder tiles to help explain that Placeholder Tiles are most commonly a result of devices getting de-authorized somehow.