Openhab overriding Jython's datetime

[rlkoshak (Rich Koshak)]

@redm

Well, the nice thing with a scripting interface is that you can hide away implementation details.

And doing that takes work. Work performed by volunteers. The answer to “why can’t openHAB just do [super specific thing that would make things easier for me]?” is always going to be either:

• it’s not technically feasible
• no one has volunteered the time to implement it.

To a large extent the Helper Library is a layer that is intended to abstract the core Java OH stuff from the native language stuff. But I actually have a concern that doing too much of that is going to result in a balkanization of openHAB Rules where Jython rules become completely incomprehensible to JavaScript users or Rules DSL users because too much is abstracted. Frankly the jRuby rules have already gone there so maybe it’s inevitable. But that is going to mean that the ability to find and understand examples that can be used to learn from is going to be come exceptionally difficult.

Right now, someone can take their already written Rules DSL rule and with just a little bit of translation in syntax end up with that same rule in JavaScript or Jython or Groovy. Once everything is completely abstracted so that only language native Objects are ever dealt with that disappears. Now to convert a rule from one language to another one would have to be an expert in both languages.

[redm (Michael)]

@CrazyIvan359

For the time being we’re stuck with Jython, and it doesn’t handle Python datetimes very well.

Yes, learned about that, too. And it seems intentional. Super weird, whoever came up with that idea…
(Strange thing is that I used Python datetime quite a bit in the past days rewriting my rules, and didn’t notice a problem… maybe I was just lucky)

@CrazyIvan359

ZonedDateTime is a Java class, documentation can be found by Googling it, Java classes are very similar to Python classes so it’s not a foreign construct to someone who knows Python.

Provided you know that. I spent over an hour yesterday trying to figure out how to do something as simple as substracting two DateTime items in Jython in OH2.5 (that’s how I came over this thread). In the end I gave up and went to bed… Just super confusing.

@CrazyIvan359

If you have contributions to the Helper Libraries documentation based on your experience learning to script in OH, they will be welcome.

Great to hear. For now I’m at least taking notes of what I find not well documented.

@CrazyIvan359

I just don’t have the time to write the book on it.

Ideally you wouldn’t have to, because it just works as you expect it to work in Python, JS, Ruby… And people already have written tons of books on each of these

@rlkoshak

And doing that takes work. Work performed by volunteers.

Sure. I was not going to demand anything. Just give my input at this point. And answering to your point that there is no way around dealing with Java stuff in JSR rules.

@rlkoshak

To a large extent the Helper Library is a layer that is intended to abstract the core Java OH stuff from the native language stuff.

Right, but it’s also something you have to install from 3rd party sources. IMHO it should be a first class citizen, at some point it it should be THE scripting API. When it had some time to mature. It should be in the official documentation. (I mean, the official scripting interface is super complicated)

@rlkoshak

But I actually have a concern that doing too much of that is going to result in a balkanization of openHAB Rules where Jython rules become completely incomprehensible to JavaScript users or Rules DSL users because too much is abstracted. Frankly the jRuby rules have already gone there so maybe it’s inevitable. But that is going to mean that the ability to find and understand examples that can be used to learn from is going to be come exceptionally difficult.

Right now, someone can take their already written Rules DSL rule and with just a little bit of translation in syntax end up with that same rule in JavaScript or Jython or Groovy. Once everything is completely abstracted so that only language native Objects are ever dealt with that disappears. Now to convert a rule from one language to another one would have to be an expert in both languages.

Yea, that’s a danger I admit. I guess the optimal way is as always “in between”. Have the OH API wrapped in a way that feels native in the respective language. But keeping the overall structure consitent, allowing easy porting. Like that in Python I can just do a str(event.itemState) instead of having to call an alien .toString(), that a StringType is interchangeable with Python string, or that I have ONE abstraction of date times (instead of 6 or how many types there are floating around…). But the OH interface, the existence of createTime, sendCommand or similar would be the same in all languages.
On the other hand, it’s just so much more pleasant to write rules just in Python and avoiding all these weird OH, Java, Eclipse types. It feels entirely different, allowing to do things differently. I think up to now there is not a single rule that I converted 1:1 (just anecdotic, yes). Replicating the complicated structure of what is used in Rules DSL is not desirable.
And maybe having the helper libs as part of OH, would allow for more coordination and less balkanization…
And Rules DSL, well, it should just die…

[rlkoshak (Rich Koshak)]

@redm

Like that in Python I can just do a str(event.itemState) instead of having to call an alien .toString(), that a StringType is interchangeable with Python string

It’s been awhile but I think that actually will work.

@redm

On the other hand, it’s just so much more pleasant to write rules just in Python and avoiding all these weird OH, Java, Eclipse types.

Again, there is HABApp. If you want pure Python without any intrusion of Java that option is available to you. If language purity is important to you, you have that option.

[redm (Michael)]

@rlkoshak

@redm

Like that in Python I can just do a str(event.itemState) instead of having to call an alien .toString(), that a StringType is interchangeable with Python string

It’s been awhile but I think that actually will work.

Ok, maybe this was a bad example and this actually works. But I had a few other place where I needed to call toString() on something string-like, intValue() on a number or similar where I expected automatic conversion to Python string or int, or str() or int().

@rlkoshak

Again, there is HABApp. If you want pure Python without any intrusion of Java that option is available to you. If language purity is important to you, you have that option.

Sure. Disadvantage is that you have another moving part to care about outside OH. And some other things were not possible. I don’t know… I went for Jython, so that is it for now. No time to redo everything.

[rlkoshak (Rich Koshak)]

@redm

Sure. Disadvantage is that you have another moving part to care about outside OH. And some other things were not possible.

TANSTAAFL

[CrazyIvan359 (Michael Murton)]

Handling DateItem data has always been a bit of a complex topic, even outside OH, but with such a diverse community in terms of programming knowledge it has turned into quite the snowball. In your case you seem to know Python, but that will only go so far until you get into the habit of thinking of the fact that you are also working inside a JVM and interfacing with Java objects. Personally I think just working with the native ZonedDateTime class is the simplest way since DateTimeType (state) subclasses from it and DateTimeItems accept it, plus it has better methods than Python’s datetime (I think) for comparisons. The core.date module has some converters and other helpful functions for working with DateTimes.