[Solved] Demo sitemap issue - Outside Weather text colour

I’m new to OpenHAB and this is my first post. Please be gentle! I have zero experience of Java, so I expect this is a dreadfully noob question.

I’ve installed openhabian OH2.51 on a RPi3 and got it working with a few MQTT lighbulbs, and thought the next step would be to copy the weather part of the demo site. I have used DarkSky and it’s pulling down all of the detailed information correctly.

The one thing I can’t get my head around is the section of code that changes the colour of the text based on Weather_LastUpdate, which is the time of the last update. It seems to me that the logic is based on the number of minutes since that update, so how is this meant to work?

The line I don’t understand is

Text item=Weather_Temperature valuecolor=[Weather_LastUpdate=="NULL"="lightgray",Weather_LastUpdate>90="lightgray",>25="orange",>15="green",>5="orange",<=5="blue"]

The value of the variable as shown by VSCode is e.g. ‘2020-01-27T18:06:25.071+0000’ and the colour is usually grey, but sometimes orange after a page refresh.

This is my an entry in a file I’ve called weather.rules (and the log shows it is being read)

// Creates an item that stores the last update time of this item
rule "Records last weather update time"
  Item Weather_Temperature received update
  postUpdate(Weather_LastUpdate, new DateTimeType())

Could anyone please give me some pointers as to what I’m doing wrong? Many thanks in advance.

In the Thing config you set how often the binding updates the weather. The rule just post the time it was updated.

Does the grey go away each time you refresh the page? In BasicUI you can use F5.

IMHO (and yours too) to correctly change the valuecolor “Weather_LastUpdate” needs to hold the timedifference between the LastUpdate and now.

Thanks for your reply. My weather.things file has the refreshInterval set at 15.

A page refresh (F5) does not change the grey to orange, but it does seem to change once the binding is updated, but then reverts back to grey after a few minutes. While checking this I increased all the thresholds by a factor of 60, and the value changed to blue … and stayed blue (I was wondering if seconds were being checked intead of minutes, but this doesn’t appear to be the case.)

I’d use a
logInfo ( "Records last weather update time", " Weather_LastUpdte: {}", Weather_LastUpdate.state)
in the rule to see the actual value in the logs.

@opus you think the issue may be the sitemap and the number format?

Syntax may not be correct but something like below might work?

rule "Records last weather update time"
  Item Weather_Temperature received update
    var time = Weather_LastUpdate.state as new DateTimeType()

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