[RELEASE] FREE Meteobridge/Weatherbridge Weather Station v 1.1.*

Actually, not if you consider compute power.

My Ecobee Suite does a TON of calculations and string manipulations for every cycle (poll) of the Ecobee servers. On SmartThings, this usually takes between 2-4 seconds; on Hubitat it is more like 5-10 seconds. And there's some sort of "leak" on Hubitat, after about 24 hours of running, the ES Manager cycles will take 25-50 seconds, while SmartThings doesn't waver.

So, I suspect that the CPU's my stuff runs on in Amazon's cloud are bigger/better/faster. I did some looped math testing, and the SmartThings CPUs are consistently 2-3x faster than the Hubitat's processor (doing the same task).

Plus, network traffic from Ecobee to SmartThings (and Alexa to SmartThings, and...) all run "local" within the Amazon cloud, where the routing latencies have long been optimized by all the traffic. Ecobee-to-SmartThings transfers happen thousands of times per second (for all the users - not just my code), but Ecobee-to-my_little_Hubitat are a tiny fraction, and involves routing through several IP routing nodes to get here.

A few milliseconds here, a few microseconds there, and things can really start to slow down.

It's because of this that I'm moving most of my cloud-based services (Ecobee, Echo Speaks, Chamberlain, etc.) back to SmartThings - better performance, and if the network is down, they aren't going to work anyway :wink:

1 Like

ah, good point. Didn't think that it would be the cloud doing processing vs the actual ST hub (vs Hubitat). =)

Hmm, guess that's a good point. So you could argue running an ST hub (linked to hubitat) with zigbee and zwave disabled (for example) and just use it as a gateway for cloud stuff.

have you brought up the "leak" to Hubitat?

Reported it a couple of times, but since I can't recreate it outside of installing my whole Ecobee Suite, they kinda just let it die...

Can't really turn off ST Z-Wave in any permanent way, so I live with the added "noise" in the system mostly. I turn it off when I'm doing adds/edits...

1 Like

I mean, I suppose that would let me move my locks back to ST's rboy drivers... since Hubitat still works like crap with my schlage locks. =(

1 Like

That's actually my primary complaint...can't get the Schlage's to pair, even.

I got them to pair, but they chew through batteries like crazy, and randomly don't respond. Reliable locks seems hacky at best (and probably why the batteries are draining). Gah... really wanted to be on a single system. =(

Guess I know what I'm doing this weekend. lol. Hopefully I can get the Schlage locks to work without moving other zwave devices over.

And here I was thinking "it wouldn't be THAT expensive to just buy a couple more Yale locks to replace the schlages with" =P

My plan is a pair of Z-Wave Range Extenders that I'll move over to the ST Hub to give it the reach it needs to get to the locks. Hopefully that will be enough. Everything else I need will be connected via HubConnect...

1 Like

I did buy some range extenders. good point....

okay, you sold me. ah well. at least the hubs don't use much power. =)

still not sure about moving ecobee or meteobridge back over. So you must have a firewall/nat rule for your MB to route from the internet?

Nope, no firewall poking for MB - it uses local hubAction for the actual communications from the ST hub, same as for Hubitat.

ugh. you can turn off zwave, you can't turn off zigbee (on ST).


Doesn't matter - Zigbee works fine with ST left on. I actually am using the same network channel for both ST and HE (24) and all 150+ of my zigbee devices are just fine.., on both hubs.

1 Like

Good to know! =)

back to original topic. Hubitat already giving "read time out" again. =(

Is this Hubitat having an issue, or MB having an issue? Don't really want to resort to a nightly reboot of either... =/

Found your post on MB forums. Switched back to 3.8 for now.

@storageanarchy Did the MB dev ever remote in and take a look at what was going on?

Yep - not sure what he did, but I've been mostly stable ever since.

I'm running MeteoBridge version 4.1 (August 26, 2019)...

Change line 590 of your Meteobridge Weather Station code to this:

            [callback: meteoWeatherCallback, timeout: 20]

Let me know if it improves things, or if you start getting a different error - I'll need to see that error, because I can't reproduce the Read timed out error...

MeteoWeather (WeatherBridge) Weather Station v1.1.29 posted on 29 August 2019

  • Now supports extended timeout on Hubitat platform
  • Now supports new 503/504 (server busy/gateway busy) error responses
  • Preference setting to skip creating the MyTile content
  • Preference setting now allows 2 minute polling cycle (was just 1,3,5,...)

Note that this works best with Meteobridge 4.1 (Aug 28 2019, build 2402) and later.

MeteoWeather (WeatherBridge) Weather Station 1.1.31 posted on 9 October 2019

Updates include:

  • Auto-reschedules polling slot if MeteoBridge reports busy (to avoid competing with other apps using MeteoBridge templates)
  • Preference setting to enable debug logging (default is off)