[Reactor] Bug when sending MQTT boolean payloads

[gwp1]

I just stumbled across this last evening in the manual and it piqued my interest in possibly using this to trigger from/by:

"Sun Information" entity (capability suninfo, canonical ID reactor_system>sun) with data about today's sunrise/sunset, day length (in hours), solar noon (transit) time, and current sun angle (-90 at sunrise, 0 at solar noon, 90 at sunset).

I immediately added the entity to a dummy/test ruleset last night and see that the value currently shown for suninfo.sun_angle hasn't budged from "-218.7", even though it's now mid-day (expectation being something between "-90" and "90" being the current value.

I read and reread the manual and don't see where there's any config required for this entity - am I missing something? Has anyone else made use of this?

[therealdb]

@gwp1 I've tried it just right not out of curiosity and it's showing -228.3 for me (and it's 20:15 here in Italy, so it should have been 90).

[toggledbits]

Can you both report the results of http://your-reactor-host-ip:8111/diag/sun please? VIA PM TO ME

[toggledbits]

Based on what @gwp1 sent, it looks correct, but like it's not updating (stale data). I'm going with that for now. Fixed for next build.

[gwp1]

This did it, @toggledbits - thanks very much for the prompt turnaround! This will lead to some interesting blinds automation, methinks....

[therealdb]

It’s fixed for me as well.

[gwp1]

Seems odd but this stopped refreshing stopped matching my location last night at 22:49 ET. The difference, however, this time is that the results of the URL are what's not refreshing. @toggledbits I've sent you the results of the URL from this morning.

Currently it is updating but the sun angle doesn't match the location of the MSR host location setting. All other data seems to match. Lat/Long, date/time, etc.

[toggledbits]

@gwp1 I'm going to respond to your second PM here, because I think it's useful public info...

The only thing that would change in the sun data on multiple requests is the sun angle, and that is changed in your two (DM) examples. The timing of astro events and the length of the day remain the same all day (i.e. sunset happens at the same time on 12/11 whether you ask at 9am or 3pm), so don't expect any change from those parts. And this is a feature; it's a Very Good Thing that these computed times are stable.

The sun angle, having single-decimal-digit resolution as presented, would for this time of year at your location not be expected to change more than once every 20 seconds. That is, the sun traverses an arc of 180 degrees in about 10 hours (again, at your location), or 36000 seconds, so a degree every 200 seconds, or 1/10th of a degree every 20 seconds. It may be a little more, allowing for round-off and precision limits.

[gwp1]

@toggledbits Totally understand.

And I'm an idiot who apparently cannot do maths this morning.

The expectation per the docs is -90 = sunrise, 0 = solar noon, 90 = sunset. The sun_angle is showing as a negative number currently, WHICH IT SHOULD BECAUSE IT'S NOT NOON YET. <smh>

Sincere apologies for wasting your time. I just installed smart blinds last evening and am very anxious to see if sun_angle will be a solid means by which to angle the blinds as the sun shifts across the back of the house - kinda let my excitement/curiosity run away with me.

[toggledbits]

All good. I anticipated this kind of application, and it makes me realize that you probably would want azimuth as well, because the effect of the sun on your windows is a function not only of its height relative to the horizon, but its angle left-right relative to the plane of your windows. That may be a bit more than you are thinking, but I think eventually you'd come to that conclusion, because the sun does change its position in the sky laterally as well as in elevation (the former is just more gradual over the course of months, while the latter is a daily traversal). So, azimuth coming next...

[gwp1]

@toggledbits Spot on, that's exactly what happens here with dramatic impact, esp on my home office. Sadly, the blinds in there are too small to automate at this time (by a mere 1 1/2", too.) The back of the house, however - totally fair game for automation.

[toggledbits]

OK. In playing with this a bit more, I'm going to make suninfo.sun_angle go away (eventually; after a deprecation period), and it's replacement will be a soon-to-come suninfo.elevation. The elevation is the true angle of the sun above the horizon. Unless you live on the equator, the sun is not really at 0 degrees at solar noon, as sun_angle indicates. For example, right now for me in the Atlanta area at this time, solar noon gives me an elevation of just 33.5 degrees (summer solstice about 80 degrees). I think the true elevation will be a better metric for solar energy calculations, and in combination with azimuth, you should easily be able to compute ray angles/exposure to solar panels and good things like that.

The other things I'm fixing is that our friends in Prudhoe Bay and Tromsø are getting incorrect day lengths, etc., right now because the sun never rises at this time of year. The sunrise/sunset times are null as expected, but the day length is 24 when, IMO, it should be zero, and the sun_angle is null which is again not as useful as having a real elevation.