Astro Binding - Is Moon phase#age - and other phase channels - not recalculated with the Thing set interval?

Just testing switching from OH2 to OH 4.3.2, and while a lot of the changes with DateTime and HSBType conversions were straight forward, I found that the Moon phase#age is now reported in seconds, but doesn’t seem to get updated with the Moon Thing interval I set (every 60 seconds)

Does this possibly apply to all the phase group channels, so that also the illumination, phase names etc. would not get updated throughout the day, like the position group channels azimuth and elevation?

Or am I missing some special new setting so that these also get updated with the Thing interval?

Thanks

I don’t do anything with the astro moon thing but I would expect it to work the same as the sun. For the sun the phases are calculated once a day a few seconds after midnight.

position, azimuth and elevation I would expect to be updated every minute the same as the sun Thing does for those Channels. I know of no configuration way to cause the Thing to calculate it once a minute, and I’m not sure what the use of doing so would be.

I imagine one could create a rule that runs once a minute that disables and re-enable the moon Thing which should cause it to recalculate the phases. But the whole thing seems like an XY Problem. Why do you want the moon phase Item to update once per minute given that there’s a Channel that will tell you the exact time when that phase will start without polling? With that you can calculate the age as necessary.

But again, I don’t use the moon Channels so I don’t know how they used to work nor how they are supposed to work.

Correct, and it’s all fine for the sun phases, as they do not change throughout the course of the day :wink: and I correct myself from the original post, in that the Moon Illumination actually also does update every minute.

As the moon phase age (new moon to new moon) does change continually throughout every day I would have expected it to also update every minute, especially as now in OH4 (and possibly already in OH3) the value is being reported as seconds, where previously in OH1/2 it was reported in days. Much the same with the Moon phase name, which can also change through a day, and close to a new moon and full moon can actually have three different states in one day (Depending really on which illumination changes you define for phase changes).

As the moon phase name is generally reported for whole days though, also with other astronomical sites or calculations, I suppose a moon phase name per day can be acceptable, but the Moon Age once a day, and then reported ins seconds, is pretty off.

Exactly my point - easily and poignantly observed yesterday and today.

Yesterday 23:59

Where the moon age was reported as 29 days 32 minutes (from my JS transformation from the initial seconds), with this age being there for 24 hours since 00:00 without any update all day.

Then shortly after midnight Today **

This is 13 hours and 36 minutes before the actual New Moon, so any age of 10 hours and 22 minutes is just completely wrong for what is supposed to be a scientific astronomical binding calculation, even without not updating throughout the day, but already for 1 minutes past midnight on the day of an upcoming New Moon.

Then several hours later today, at 11:10, just over two hours before the actual New Moon it all still looks the same for the Moon Age

Then comes the actual New Moon event at 13:37, when shortly after at 14:05 nobody can really deny that the Moon Age is supposed to start brand new, but what do we get?

Same old 10 hours 22 minutes, which will stay like that until midnight today again.

Even right after midnight this morning this 10 hours 22 minutes age is the actual age of the moon at midnight tonight, so a value in the future, after the actual New Moon event today, but already shown through the whole day, when it is actually totally wrong for 23 hours and 59 minutes of then day :frowning:

So the Moon Age is always only correctly reported just after midnight every night, but that’s it. With OH2 and its reporting in days at least this changed to 0 days for the whole day, much the same as the constant Moon Phase name

Sure I can adjust my JS transformation again to only report in days, I just assumed that with the change to the Moon Age being reported in seconds now, that at least this also came with an improvement in accuracy and progressive reporting of the age, but alas, it only seems to be a unit change :frowning:

Exactly, I can always see the exact date and time when the next phases will occur, as I have put into my Moon Phases section, but then it just makes me cringe when the above age is so obviously completely wrong when seeing the two sections together.

I surely could, but with the Astro Binding supposedly reporting the age why should I, or anyone else, have to recalculate it just to get a correct result. Should that not be happening with the phase#age already?

Yes, would also work, but again a pretty hacky way of getting a result which, in my opinion, should already be sensibly handled by the Astro Binding.

As I say, I’m just evaluating OH4 to see if and when I might switch over from OH2, and just pointing out my disappointment when first seeing the moon age being reported ins seconds now, but still only disappointedly recalculated once a day just after midnight giving the above shown wrong results.

It probably is being reported in days. But if you’ve not set the unit metadata on your Number:Time Item to d the days are being converted to the system default unit which is seconds.

According to the description of the Channel in MainUI it is reporting the time in days.

image

This is how all Items with units work. If you do not set the unit metadata on the Item to what you want, the system default is going to be used regardless of what unit is published by the binding.

I did a little search, and nothing related to the moon age channel has really changed since OH 2. I may have missed something, but it’s likely working as it always has.

But you are free to file an issue if you want it to calculate the age differently. Personally, I think you are drawing incorrect conclusions based on the fact that the days is converted to seconds becuase you didn’t define the unit metadata on the Item.

You don’t need a transformation in the first place. Just set unit="d" on the Item assuming text file Items or click “add metadata” and choose unit in the UI for the Item.

In OH 4 the whole way units are handled has been implemented so that you have full control over the unit used and you can always know what the unit is. But to do that some rules had to be developed.

  • if it’s a Number Item without units the units are stripped off any update; no longer can a Number Item suddenly carry a state with units
  • if it’s a Number:x Item the state will always have a unit
  • if there is unit metadata defined on the Item, that is the unit the Item will always carry. Any update sent to it in any other compatible unit will be converted to unit
  • if there is no unit metadata defined on the Item, the system default unit is assumed. The system default is based on the regional settings (e.g. for Imperial regional settings the default unit for Length is feet and for SI it will be meters). Again, any update sent to the Item will be converted to this unit
  • the Item label/state description has no influence on the actual state carried by the Item and is only used for display on the UIs.

Prior to this (i.e. OH 4.0) there was no rational set of rules for how units were handled.

Moon phase#age is being reported at the interval set in the Thing config.
I tested this myself by setting my moon Thing interval to 10 (seconds). However, although the binding does update the item every 10 seconds, the value doesn’t seem to change.

I’m not familiar with the moon phase (haven’t read up on it). Is it supposed to change continuously?

Thanks @rlkoshak

I’ll definitely have to look into the new unit handling of OH4.

But looking closer at the OH2 Moon Age, the days there are also already reported as a float for days. So a more refined Moon Age would have already been possible there if updated regularly.

The ways it is now the Moon Age can only ever be displayed in integer days for a whole day, but not correctly constantly updated. Which, in light of the existing varying lunations (lunar months), is likely a missed chance for a more scientifically informative Astro binding.

If you want DD:HH:MM:SS you can set a DateTime type state description pattern on the label. This will work even if the unit is days.

For my UPS expected runtime I use: %1$tH:%1$tM:%1$tS which renders the Number:Time as

Use %1$td to use days as well. There was some work on this awhile back to make the formatting work as expected for Number:Time Items. In OH 3 and before, a hack was used by adding the time duration to epoch and creating a date time out of it but that only worked with time durations less than 30 days. It now has it’s own independent implementation and no longer has that limitation.

Of course, if you want to get fancy (e.g. don’t show the days field if the number of days is 0) you’ll need a script transformation.

You could also get simple and use %.2f d which will show the number of days with up to two decimal places.

My basic understanding of what the age of the moon phase means it should change. The age should be how much time has passed since the start of the current phase if i understand it correctly.

Even though the behavior may not have changed on this front is no reason it cannot be changed and improved in the future. But for that an issue will be required and eventually someone to volunteer to submit a PR.

I doubt a lot of people use the age of the moon phase in their home automations which is probably why no one has had an issue with the current behavior.

I have my original OH2 moon Thing brought over with interval=60 and all the moon Items based on this single Thing, e. g.

Number:Time             Moon_Age                                 "Moon Age [JS(Uptime_from_seconds.js):%s]"                <moon>                                               {channel="astro:moon:home:phase#age"}
Number:Dimensionless    Moon_Illumination                        "Moon Illumination [%.1f %%]"                             <moon>                                               {channel="astro:moon:home:phase#illumination"}

with the second Moon_Illumination (as well as position#azimuth and position#elevation) being correctly updated every 60s, but phase#age only once every 24 hours, just after midnight.

So would I need to create a separate phase#age Thing with a dedicated interval?

To be correct and actually useful, yes, I would say I would need to update continuously :wink: like with my screenshots above, even though a bit overkill, Just before the New Moon date today at 13:37 the age should have been 29 days, 14 hours, 8 mins, while a minute after 13:37 it should have been 1 minutes - instead of showing an indiscriminate 10 hours 22 minutes for the whole day.

Much like the Illumination, which constantly changes, and would be quite strange to only have one single value throughout the whole day.

I don’t use it either for any automation, but with this obviously wrong 24-hour static display it sort of also makes it easy to mistrust any other possible values created by the Astro Binding when glancing at this wrong value. Like my example above, what if Illumination would just be one single value for every 24 hours.

Continuing my OH4 move evaluation - just updated my MiLights with the now integrated MQTT EspMilightHub Binding …

@Hans_Lree please test this jar file that corresponds to your oh version (5.0 or 4.3.x) (disable your built in one)

org.openhab.binding.astro-5.0.0-SNAPSHOT.jar.txt (128.8 KB)

org.openhab.binding.astro-4.3.3-SNAPSHOT.jar.txt (128.7 KB)

Rename / remove the .txt extension and drop it into your addons folder.

Many thanks @jimtng! :+1:

Using the 4.3.3 Snapshot .jar with the current GM 4.3.2, and looks great, with the Moon Age updating every minute (interval setting) along with the other regularly updating items.

Screenshot with my days/hours/minutes script transformation

PR: https://github.com/openhab/openhab-addons/pull/18203

I’m not sure whether this is considered a bug, and thus, be backported to 4.3, or only included in 5.x. In any case, you can keep using that jar for now.

2 Likes