Here is
c:\openHAB>java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
Here is
c:\openHAB>java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
OH3 requires Java11, which is what the error message is telling you.
Oh, thank you!
Itās a community project if you think something is not good enough ie the documention you can suggest changes.
I donāt think you need ā{ā
Iām sorry to insist on this one, but IMO, OH should not throw such error upon unexpected request ( Content-Type
header is not mandatory upon RFC7231). Although I agree that the HB module should be more accurate in its request, it is a regression as it was working on OH2, and not anymore in OH3 (change of behavior).
It also generates pollution to have those errors in the stack trace
May I suggest to handle the default behavior as text/plain
instead of application/octet-stream
? I know that the RFC7231 mentions that the default is application/octet-stream
, but it also mentions:
[ā¦] or examine the data to determine its type.
It would as such not be a deviation to the RFC to try to figure out if the POST payload is text/plain
instead of application/octet-stream
.
I also think it would be much quicker to have this fixed in OH3 rather than in the HB module
And hopefully willing to contribute to building up the docs? There are several wiki posts already to get started.
As you run into something you donāt understand or canāt figure out how to do, please go to these topics (note there are several posts for each thread) and if you canāt clarify the documents, please at least post a reply or edit inline with the question or request for clarification.
The docs wonāt be any good without contributions from the community, especially early adopters of OH 3.
This is just a general question and not meant to push anything but more to understand the intended direction of the future of OH.
There was discussion in previous threads of making Python/Jython a āfirst class citizenā as it were for programing rules in OH3. OH2 requires a lot of set to make it work, which Iāve successfully done, and itās not difficult, just requires effort.
Are there still plans to integrate it better into OH3 or will the config be about the same as OH2? I value Python integration greatly as it really makes OH2 an amazing tool and opens a lot of possibilities. Either way I just donāt want to see Python/Jython dropped from OH3, which Iām assuming is not the plan.
More just for my own understanding of what the developers are thinking.
Thanks for the hard work all!
Have you tried with a clean database? You should try the fix with a clean db or with one migrated from OH 2.0.
If the DB has previously written readings from OH 3.0 nonfixed addon itās normal it fails.
@4u2fast Do you use MapDB to restore values on startup?
We have some discussion here and it may be the cause:
Is there a possibility to āAdd ALL Points/Equipment to Modelā in the new UI?
Donāt know, if I missed something, but as far as Iām concerned, I do the following:
So, is there a faster way to ācheck allā checkboxes at once?
This is being discussed on GitHub at the moment. Short answer it canāt be done yet, long answer is in the GitHub issue.
Looks like a commit has been done already.
umā¦ YEAH !
??? what is the deal with all of Scottās hard work not being included???
Iāve being watching on git and really wonder what is the hold up
yeah bruce i read that
I have 2 issues after update from 2.5 to 3.0ā¦
I followed the instructions and all configurations,items,influx database were moved ok.
I can see al info running through grafana server butā¦
if Iām logging at http.//localhost:8080 I can see the old dashboad vers 2.5.9 and without any items,things,rules, all gone.
But I removed all directoy belong to openhab2, why do I have still the old dashboard?
tks
I donāt recognise an answer to this. From my point of view there is currently no select all feature. In addition tehre is no copy feature to copy and thing or items as a base for a new thing/item.
The only was to speed it up is to click faster
Sounds to me as if you still have your openhab2 instance running in parallel - can you rule this out?
We are still waiting for something that can be included, but instead of helping moving things forward, Scott seems to prefer to play dead and not respond anymore. Maybe just to my questions, so I will stop trying now and focus instead on the hundreds of other maintainers who contribute valuable features and are waiting patiently since months for reviews and feedback.