Use DateTime item out of one item into first item's name?

Setup, Configuration and Use Items & Sitemaps
1

Hi there,

Let’s assume those two items from OWM, whose information belongs together:

String localDay2Condition  "Prediction day after [%s]" { channel="openweathermap:onecall:api:local:forecastDay2#condition" }
DateTime localDay2Timestamp "[%1$td.%1$tm.%1$ty]" { channel="openweathermap:onecall:api:local:forecastDay2#time-stamp" }

In BasicUI & OH App I would prefer to have both information combined into one line/entry like:

🌦️ Prediction for "$localDay2Timestamp" "$localDay2Condition"

So, simply placing item “localDay2Timestamp” somewhere into that item’s name:

String localDay2Condition  "Prediction day after [%s]" { channel="openweathermap:onecall:api:local:forecastDay2#condition" }

?

2

In sitemaps you’ll have to create a new String Item and a rule to combine the two states from the two Items into one.

1 Like
3

Ok, I feared that, but the output would then not like I thought to be it and rather look like e.g.:

🌦️ Prediction for "$localDay2Timestamp":"$localDay2Condition"

4

Sitemaps are great because they are easy to set up. But that also means your opportunities for customization are limited. :person_shrugging:

In MainUI, you have a lot more customization available but that makes it more complicated.

You can change the label for the new Item to include the timestamp (you can change the label of an Item from a rule) but it’s still not going to look like you describe I think.

5

Hmm, ok, so item’s name cannot be (partially) variable, except e.g. some [MAP … :%s], right?

6

From a rule you can change the Item’s label.

For example (in JS):

items.localDay2Condition.rawItem.setLabel("Prediction day after " + items.localDay2Timestamp.state + " [%s]")

I don’t have a lot of experience with these but I do know it’s possible. You’ll have to experiment.

It has to be done from a rule though.

1 Like
7

Ok, solved it using a DSL rule:

rule "AddLocalDay2Datestamp"
when
   System started or
   Item localDay2Timestamp changed or
   Item localDay2Condition changed
then
   if (localDay2Condition.state != NULL && localDay2Timestamp.state != NULL) {
      localDay2Condition.label = "Forecast on " + localDay2Timestamp.state.format("%1$td.%1$tm.%1$tY") +" [%s]"
   }
end

Only thing I need to think about, are the “if” conditions actually really needed …

8

Well, for the if condition, it would suffice to check the Timestamp (but better don’t check for NULL but instanceof DateTimeType

if(localDay2Timestamp.state instanceof DateTimeType)
    localDay2Condition.label = "Forecast on " + localDay2Timestamp.state.format("%1$td.%1$tm.%1$tY") +" [%s]"
1 Like
9

Yes, can consider that, thanks.

Down the line it would not break a thing here, if states are not proven. Its just manipulating output strings. As long as openHABian and bindings are running properly, the items should always have proper value. And if not, well then I can see a weired or no output for short time …

But same when “if” condition doesn’t allow string manipulation, I will see either an old output or no output …

10

Well, the point is, if the datatype isn’t of type DateTime, the format string won’t be valid, this will (most likely) lead to a nullPointerException and in consequence the rule will fail at this point.
If the if condition is the last line of code (except the conditional code of course) this will do no harm, but it’s bad style not to check :wink:

11

Well, in that specific case I have a different view, that string output might not be correct, proven or not. Its just a string output manipulation.

Unlike a rule where something fundamental does happen. In those cases there’s no discussion about it. I usually proof extensiv various states, before allowing any real device is allowed to get in charge.

1 Like