Plugin: Weather4Lox (ehemals Wunderground4Loxone)

[Prof.Mobilux]

This is no plugin issue. You have to make sure that your router routes packages between your two networks 192.168.30.x and 192.168.40.x

[edipseamm]

For others ref: The issue is unifi. Does not pass correctly. Fixed by putting pi and device in the same subnet

[Mex]

Hallo

Ich habe eine Frage zu den Icons.
Und zwar versuche ich gerade das entsprechende Icon vom Wetter auf ein Sonoff NSPanel zu bekommen.
Dazu müsste ich es aber erst schaffen das Icon entsprechend auszulesen.
Dies gelingt mir aber nicht. Bzw. habe ich hier auch ein seltsames verhalten.
Und zwar hat sich heute das Icon in der Loxone App mehrmals geändert von Bewölkt auf Regen...
Aber wenn ich auf die Webpage von Weather4Lox gehe habe ich heute den ganzen Tag schon das gleiche Icon.
Welche Möglichkeit habe ich dass ich das Icon (den Befehl) dass an den Miniserver gesendet wird abzugreifen um immer das richtige Icon zu haben?

Ich hoffe ihr könnt mir hier weiterhelfen.
Ich habe über die Suche zu dem Thema leider nichts gefunden.

Bilder mit einem aktuellen Stand habe ich angehängt.
Die Screenshots habe ich zur selben Zeit gemacht.


Danke euch!

[Prof.Mobilux]

Also der Unterschied zwischen Webpage und Loxone App ist, dass Loxone nur einmal die Stunde die Wetterdaten abruft (immer so kurz nach um). Der Webpagebaustein hingegen aktualisiert sich bei jeder Abfrage der Wetterdaten. Als nächstes muss man die Wetterart, die der Webservice ausliefert, in ein passendes Icon übersetzen. Das machen die Grabber im Plugin. Es gibt aber nicht überall die gleichen Icons, von daher kann sich das schon auch mal unterscheiden. Wobei "Regen" und "bewölkt" hier schon unterschieden werden. Ich tippe also auf Ursache Nummer 1.

Das Icon kannst Du in der Loxone abgreifen, indem Du Dir einen Virtuellen Eingang für "cur_we_icon" anlegst:

https://wiki.loxberry.de/plugins/weather4loxone/start#verf%C3%BCgbare_wetterdaten

[Mex]

Danke schon mal für deinen Input. Aber leider bekomme ich weder über UDP noch über HTTP "cur_we_icon" angezeigt.
Aktuell sieht es so aus:
cur_date@456143820
cur_day@16
cur_month@6
cur_year@2023
cur_hour@10
cur_min@37
cur_loc_lat@xx.xxxxx
cur_loc_long@xx.xxxx
cur_loc_el@-9999
cur_tt@19.2
cur_tt_fl@22.8
cur_hu@62.0
cur_w_dir@167
cur_w_sp@1.1
cur_w_gu@1.8
cur_w_ch@22.8
cur_pr@1016.9
cur_dp@12.5
cur_vis@10.0
cur_sr@373
cur_hi@-9999
cur_uvi@3
cur_prec_today@0
cur_prec_1hr@0
cur_we_code@3
cur_moon_p@12
cur_moon_a@-9999
cur_sun_r@456123660
cur_sun_s@456181020
cur_ozone@-9999
cur_sky@38
cur_pop@0
cur_snow@0.00

Das ist alles.
Und ich habe zum testen trotzdem einen solchen Eingang angelegt und auch den UDP Monitor bemüht, aber wie gesagt bekomme ich kein Icon.
Kann es am Anbieter liegen dass dies erst gar nicht angezeigt wird?
Ich nutze aktuell Visual Crossing.

Danke schon mal!

[Prof.Mobilux]

Ja, stimmt. Das senden von "cur_we_icon" haben wir irgendwann mal deaktiviert. Weiß gar nicht mehr warum... Du kannst aber alternativ einfach "cur_we_code@3" auswerten. Da hast Du direkt den numerischen Wert, mit dem Du in Loxone weiterarbeiten kannt. https://wiki.loxberry.de/plugins/wea...t#wetter-codes

[Mex]

Super perfekt danke!
Jetzt funktioniert es

[TomekWaw]

Hi, I have a hard time understanding how things work here.
I use Visual Crossing for forecast (A), with current data overwritten with nearby WU station (B). In addition to that I overwrite outdoor temperature with my own SHT35 sensor (C).

Result:
- my SHT35 sensor almost perfectly matches nearby WU station temperature (with a difference usually within 0.1 deg C). So C=B.
- Loxone Apps shows value C in weather section (and this is perfect)
- Plugin plugins/weather4lox/webpage.html shows value B (and this is reasonable)
- BUT weather server temperature input in Loxone Config shows a very different temperature - currently 1,4 reg C lower! I'm not sure if this is A, but this is not OK. To my understanding it should show either B or C (B most probably).

What am I missing here?

[Prof.Mobilux]

Originally this value is from the Loxone Weather Service (in your case from the LoxBerry Weather Service). Since you use a WU station in the Plugin, this temperature is in your case the one from the WU station OR (depending of your plugin configuration) the measurement from your SHT35 (if you enabled the Loxone grabber in the plugin). The sequence the plugin uses the different values is as follows:

1. Weather data from the weather service
2. If enabled: the data is overwritten by the Wunderground grabber
3. If enabled: the data is overwritten by the FOSHKplugin Grabber (another LoxBerry Plugin)
4. If enabled: the data is overwritten by the WU Upload Catcher Grabber (another LoxBerry Plugin)
5. If enabled: the data is overwritten by the Loxone Grabber

So if I understand your setup correctly, the data from Visual Crossing is first overwritten by the WU station near to you and then overwritten again by the data from the Loxone Grabber (so temperature from your SHT35). This is then the data the plugin sends to the MIniserver.

The fact that you see a difference between your SHT25 and the "W - Temperature" block is, that Loxone only grabs the data from the plugin once an hour. So worst case the value is 60 minutes old.

[TomekWaw]

Prof.Mobilux Thanks for your answer. I thought it works this way but apparently it isn't in my case. Here's my configuration:



So I overwrite current weather data with WU Grabber, but do not overwrite (current weather service data) with Loxone Grabber.
I only have Temp and Humidity, so I just assign SHT sensor value to VAR temperature and humidity. That seems to work to have it system-wide.

What worries me is why Weather Service (W) temperature input is so off.
I know that Miniserver pulls that only once per hour, but I've checked it several times in minute :00, :01 and :05 and it is still off buy a large margin.
The screenshot I've posted before was taken in minute :02, so is should match.
To my observations the difference keeps has been staying in range ~1.5-2 deg C most of the time during last 2 days and I hardly believe temperature changes 1.5-2 deg C every hour.

I do another set of screenshots right now (time is 15:02 - just after full hour):


My Outdoor SHT Sensor shows 17.7 deg C and this temperature is shown by loxone app:




Nearby WU station shows 17.7 deg C and this temperature is shown by plugin webpage:




So I'd expect to see 17.7 also in [W] (current) temperature input. But instead, 18.8 deg C (!) is shown.



So this is off by 1.1 deg C. How come?

[LoxLin]

same here

[Prof.Mobilux]

Reaty don't know. This VAR is set by Loxone. But Loxone grabs around full hour as far as I have seen +15 minutes. So waiting 2 minutes is not enough.

Why not jsut ignoring it?! You don't need this variable as long as you use the systemwide outside temperature VAR.

[TomekWaw]

Prof.Mobilux Unfortunately I can't just ignore it because of those 2 reasons:

1) If I wouldn't have my own outdoor SHT sensor - I wound never have exact temperature in my system (from nearby WU station). This makes using plugin (and WU current data overwrite) pointless, doesn't it?

2) Yes, because (and only because) I have my own SHT sensor in Loxone, I might ignore current temperature and humidity values from Weather.
But I don't have lot of other weather measurements and not all weather inputs are exposed to system as VARs.
Perceived temperature, Pressure, Radiation, Wind Direction, Particulate polution - they all are available only as Weather inputs.
And they all are off / not usable.

[Prof.Mobilux]

Use "cur_tt" Input from the plugin and you are fine. This is the temperature fromn the WU station (if you use the WU grabber). Or use the systemwide outdoor temperature VAR-block which you can set by your own temperature sensor.

No need to use that Loxone W-block which is updated only once in an hour.

[Prof.Mobilux]

Ich ignoriere nichts. Nochmal: das ist ein Thema von Loxone, nicht vom Plugin. Erst lesen, dann herumpoltern.

[Prof.Mobilux]

Sehr gerne. Hier abschließend meine Empfehlung: https://shop.loxone.com/dede/wetter-...-10-jahre.html

[Prof.Mobilux]

Hach, Du bist echt wonnig. 2 Beiträge in 4 Jahren hast Du zur Community beigetragen. Niedlich.

[TomekWaw]

Guys, Prof.Mobilux might be right here, its a matter of how Loxone polls that data. See screenshot below:




So somewhere close to minute :00 raws in this xml shift up.
As I understand this, WU Station always overwrites the top row (weather in current hour).
But before plugin does this (usually every 3 minuts) it seems that Loxone polls it just before.
So here 26.1 deg was at the top row for a minute or two and than the row has been overwritten with WU current data.
But 26.1 will be kept by Loxone for next hour (15.00-16.00).

Perhaps kind-of solution to this would be never letting Loxone read the top row if it was second row before (= before overwrite).
So if any overwrites are used, the row shift should be preceded with WU Station forced call and data overwrite first.
That would not make the weather data in Loxone perfect for whole hour, but at least it would make them as close to exact as possible for first part of the hour.
Prof.Mobilux do you think it's possible?

[Prof.Mobilux]

TomekWaw Problem is that you never know when Loxone will grab for new data. It can take up to 15 minutes (as I have seen so far). And the different sources (UDP inputs, HTTP inputs, Weather WebPage, Weather Service Emulator) are all feed from the same internal plugin database. No chance to just update one of them.

But as already mentioned before you do not need that silly W-block - even if you have no own temperature sensor.

Mark the "System Variable --> Outdoor Temperature" in the Periphery Tree, click "Define Value by Logic" and drag it into your program:



If you want to use your own temperature sensor, feed the new VAR block with the output of your sensor. The VAR block is updated as soon as the value of the sensor changed. You can use it as outdoor temperature in your whole program.



If you do not have an own sensor or if the sensor is broken, just create a Virtual UDP input with "cur_tt" from the plugin and use this one as input for the system variable. cur_tt is the temperature from the WU station if you use the WU grabber. Again the system variable is updated as soon as the plugin has new data available.



You can also build a logic to select one of the two sources (sensor or WU station) with a Analogue Multiplexer - depending of e.g. if the sensor health is OK or not. Note that in all cases your program stays the same, only the input of the VAR block changes.



I never used that scary W-block from the Loxone weatherserver, because it holds outdated data and you never know what you get.