[DEPRECATED] Free Meteobridge Weather Station 1.0.*

Devices & Integrations
42

I am seeing this in logs:

[dev:26](http://10.0.6.4/logs/past#dev26)2019-03-18 03:13:07.637 pm [error](http://10.0.6.4/device/edit/26)meteoWeatherCallback() - Missing hubResponse.json (200)

[dev:26](http://10.0.6.4/logs/past#dev26)2019-03-18 03:13:07.635 pm [debug](http://10.0.6.4/device/edit/26)meteoWeatherCallback() headers: [http/1.1 200 ok:null, connection:close, transfer-encoding:chunked, content-type:application/json;charset=utf-8]

[dev:26](http://10.0.6.4/logs/past#dev26)2019-03-18 03:13:07.634 pm [info](http://10.0.6.4/device/edit/26)meteoWeatherCallback() status: 200
43

Yes, it uses local hubaction() call so that the inquiry goes directly from the SmartThings hub to the Meteobridge. I’m not sure what the equivalent is for hubitat…

44

it SHOULD be the same. But for whatever reason hubResponse is getting the code 200, but none of the json (log.info "meteoWeatherCallback() response: " + hubResponse.json) earlier in the hubresponse block just generates “null”.

So trying to wrap my head around what Hubitat is doing…

45

You can find links to my various Weather Station dashboard here (I maintain 2 locations)…

https://www.chezburke.com/index.php/8-weather/2-weather-stations-and-dashboards

46

I see that hubResponse.json is null. You probably should do a debug statement that dumps out hubResponse in its entirety, just to see what data (if any) is being returned…

47

nope, it doesn’t. Tried a

log.info "meteoWeatherCallback() response: " + hubResponse.dump()

and it’s just blank.

The weird part is it acts like it’s working. Takes the 7 or so seconds, doesn’t give an error, etc. It’s just blank. Wonder if the GET statement isn’t right for Hubitat…

48

Well, it SHOULD have at least printed out hubResponse.status. Try just

log.info "meteoWeatherCallback() response: " + hubResponse

49

tried that too. just got the object pointer… like @1dxxx type answer. =/

50

I think you needd to change the definition of the hubAction call in getMeteoWeather from:

def hubAction = new physicalgraph.device.HubAction(

to

def hubAction = new hubitat.device.HubAction(

Hubitat documentation on hubAction is here:

https://docs.hubitat.com/index.php?title=HubAction_Object

51

yup, already did that. =)

My fork is here: https://github.com/staze/MeteoWeather/blob/master/devicetypes/sandood/meteobridge-weather-station.src/meteobridge-weather-station.groovy

52

Am I able to eliminate the PWS piece of it and pull everything from DarkSky?

53

Not the way it is currently designed, no.

54

okay… so it appears I need to specify: “hubResponse.body” rather than “hubResponse.json”.

Now looking into why forecast (line 1433) is failing.

55

alright, seeing two more. Thanks for helping with this, btw.

dev:262019-03-18 06:13:32.151 pm errorgroovy.lang.MissingPropertyException: No such property: yesterday for class: java.lang.String on line 1439 (meteoWeatherCallback)

and

dev:262019-03-18 06:12:55.909 pm errorgroovy.lang.MissingMethodException: No signature of method: java.math.BigDecimal.isNumber() is applicable for argument types: () values: Possible solutions: signum() on line 1105 (darkSkyCallback)

I assume the second one is just I need to figure out where the isNumber moved to. The former one… I’m not sure about.

56

At 1433 the code falls back to use the Weather Underground data, but that is no longer available. I meant to change that to use the new TWC day instead.

The iNumber problem is probably because the data hasn’t been loaded/saved yet.

The missing “yesterday” data is probably due to all the crashes trying to get the data from the MeteoBridge. It only requests yesterday once or twice a day - you may need to force it to get that data once, then things should be fine.

57

not sure how to force it to grab yesterday, but I’ll look at that.

fixed lat/long. Hubitat didn’t have them set. DOH!

58

When you get it all working, let me know and I will look into merging your changes to make a version that will run on either ST or HE platforms.

59

I think I got it. https://github.com/staze/MeteoWeather/blob/master/devicetypes/sandood/meteobridge-weather-station.src/meteobridge-weather-station.groovy

I had to run the hubResponse.body through the JsonSlurper which properly set types of the values. I then had to go in and remove a ton of “isNumber” checks since they weren’t strings, and would crash the driver.

I’m not a super experience github user, so I’m not sure how to actually look at pushing code back to you… but hopefully you can easily diff the fork and make adjustments.

Ping me when you want me to give it a shot. Thanks for being willing to unify the codebase. =)

60

Weird - the isNumber() checks shouldn’t break things - I used them to make sure the values weren’t null or “” (empty strings).

I will review your changes in the next couple of days and look at what it is going to take to merge the two versions.

61

so isNumber breaks if what you’re feeding it isn’t a string. isNumber and toInteger are both string functions. Because they’re already typed to being integers (or decimals), those functions are causing errors so it doesn’t finish.

Just checking for null or a “” string should just be if (whatever) {

That should return true if it’s defined, and false if it’s not. But my groovy/java is weak, so I am not 100% positive on corner cases.

Thanks! Good luck and let me know if you need any info.