[Solved] Demo sitemap issue - Outside Weather text colour

As long as the item that is used to determine the colour of the displayed item is just holding a DateTime (like “2020-01-27T18:06:25.071+0000” or better this in msecs since…) the check against the values 90, 25, 15 etc will always find the items state larger!
IMHO values that have been updated 90+ minutes before should be grey, those that are updated 25+ minutes ago should be orange…

The value is already appearing in the logs an the same format i quoted

2020-01-27 21:45:21.115 [vent.ItemStateChangedEvent] - Weather_LastUpdate changed from 2020-01-27T21:30:20.001+0000 to 2020-01-27T21:45:20.000+0000

I’d agree with your later post that the comparison vales seem reasonable if they are minutes.

I guess you are not getting the point.
Your item Weather_LastUpdate gets updated with the actual time whenever the temperature gets an update.
For the different valuecolors you need the TIMEDIFFERENCE between Weather_LastUpdate and the actual time when you display the temperature. This difference should most probably be calculated in minutes.

If you are just chasing this down for the learning experience, you might find it better to try setting text colours on a temperature Item or similar.

Oh I completely agree and understand, but I can’t believe that the demo files have this “coding error” without it being noticed before. I’m assuming that the code written is a valid sytax for doing this type of comparison within OH2, and somehow I’ve messed up when moving to the DarkSky binding.

Assuming I need to rewrite this code, can you suggest a statement to subtract the LastUpdate time from the current Date and return it in a variable as n minutes? Or point me to somewhere with similar examples?

Thanks again for your help

This is your opportunity to refine your forum search skills. There are lots of postings here, and it is an art to choose search terms to get narrowed results.

Handling datetimes in Items and rules is quirky, foundation here -

1 Like

Where is this demo file with a coding error located?I’d be happy to change that…

Unfortunately I’ve been doing exactly that for the past week, and turned to posting in the forum in desperation! I’ve already read the tutorial you’ve linked to, but didn’t progress with it as I assumed the demo code was right. As it appears that is not the case, I’ll give it another go tomorrow.

The demo sitemap was an option on openhabian’s start page (http://openhab:8080/start/index)
Everything is in the .items .sitemap and .rules files

Something like this rule should do:

rule "Timedifference"
   Time cron 	 "0 0/1 * 1/1 * ? *"  
val oldDate = new DateTime((Weather_LastUpdate.state as DateTimeType).calendar.timeInMillis)
val newDate = new DateTime(now())
var double diff = (newDate.millis - oldDate.millis)/60000

The “TimeDiference” is the new item which has to be checked in the sitemap.

Filed an IssueReport concerning the Demo.sitemap.

Thanks for that, I’ll give a proper test tomorrow, but seems to be working so far.

FYI I did get a warning in the logs, but I’ll leave that for when I’ve built up a bit more experience!

2020-01-28 00:22:14.303 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'weather.rules', using it anyway:

The method getCalendar() from the type DateTimeType is deprecated

I appreciate all your help

For anyone else following this thread, the following line has to be put in the .items file:

Number TimeDifference "Mins Since Weather_LastUpdate" <none>

and the comparison statment above has to be something like this:

Text item=Weather_Temperature valuecolor=[TimeDifference>90="lightgray", TimeDifference>30="red", TimeDifference>20="orange", TimeDifference>6="green", TimeDifference<=5="blue"]

As we’re using a different variable to set the colour, the TimeDifference Item has to be used for each condition. I also removed the Null condition, as the variable is a numeric type.

But when OH is first started it will be NULL unless you use persistence.

1 Like

Hmm, I didn’t get one, which version are you on? I’m on 2.5.0
Edit: I was probably a bit late last night; I did have the same warning! Sorry for that!
Using .zonedDateTime.toInstant.toEpochMilli) instead of the .calendar.timeInMillis) will remove the warning.

I’m glad you got it working! The NULL check was in case of an uninitialized item.

Regarding the Demo.sitemap, I would call it “not working as expected” since the used code is working without an Error… My guess this didn’t get noticed since it runs without Error and the output in this case is not showing the line in question. Let’s wait and see what the Admins say.

1 Like

Thanks, that does indeed remove the warning.
I think the demo.sitemap has a few broken parts as there is no weather data being gathered e.g. the chart isn’t working either. For me, it would have been helpful to have had a fully working demo as a starting point, but as this project sems to be moving so fast, and has so many ways of doing the same thing, I can understand how it became this way. The learning curve is very steep, and is littered with speed bumps such as these!

1 Like

A big criticism of OH is how slow it moves.
Home Assistant releases a whole new version every 2 or 3 weeks.
OpenHAB is definitely more stable and flexible though.

From an outside perspective, the pace of development does seem to be fast, and confusing! For example, many posts state that the use of text files is depreciated, and to use PaperUI, yet others disagree. Which way to go? I thought the new embedded MQTT would be the right thing to use, only to learn last night that it’s no longer being developed : use mosquitto! I’m not criticising in any way, but when a novice starts with zero knowledge, it’s difficult for them to pick the path of least resistance.

I did consider using HA, but OH seems to support more of my devices. I’m a linux user, so I prefer slow and stable over constant updates! (Yes, I abandoned Win10 for that very reason!)

You are reading a forum, old threads don’t get deleted, bindings do change,…
Take MQT binding for example, you will find lots of posts for MQTT, most do not give a version number. Chances are high that those posts reflect MQTT version 1.
That is the downside of a forum, yes it can get confusing, but there are users active here to help overcome such problems.

1 Like

I remember a few years ago Solaris server admins being mad due to an OS bug that required a reboot every 360 days. That rebooting messed with their server up-time that had been measured in years.

I used to be a Solaris admin :nerd_face: and I too got annoyed when the electricians made me turn off my Linux servers with 3 years uptime!! I’m far more chilled these days :sunglasses:

1 Like