@hafniumzinc So, finally after restarting the warning is gone - maybe I haven’t restarted after every try yesterday… so seems to be deprecated to use uppercase for ON and OFF.
thanks a lot for all your help everyone!!
1 Like
As said before, the things file parser silently ignores made-up syntax. So it would ignore this, and default on= parameter - but by chance the payload is “ON” anyway, no error to report.
This config is broken, but the channel works despite that.
I don’t think ON= was ever supported.
1 Like
maybe, but I could swear I copied this definition from an old documentation ages before 
or maybe from a forum post about mqtt…
never had any problems… but I’m glad it was just a syntax error and this will never happen to me again…
I know that I repeat myself: this wouldn‘t have happened if the configuration had been done in UI.
2 Likes
Yes sure… would be nice if you could take the time to add various things items and rules to the UI for me then… there are just 59 things and 1460 items - have fun!
sry but this is really a dumbass comment Jan…
How much time did you spend sorting this glitch out …
I still use files for what I think are good reasons (for me). But I recognise that I have to be precise. When I mess up, it’s me that’s messed up. Not the fault of deprecation or someone elses’s posting etc.
1 Like
You can import the items file in 10s, there‘s an option for that in the UI.
For things: you can retrieve all things as JSON, remove file and add them back (individually) via the REST API. This takes about 20-30s per thing. Finding this mistake took way longer.
In general it’s hard for me to understand why the devs obviously don’t have much love for textual configs anymore… all new features according to the model etc. aren’t documented what syntax one should use for textual config. I use openhab since it’s birth, in 2015 I think. I have taken part in all the time watched every change - the useful and the not so useful. but until OH 2.5 most of the first-time users used config files - I don’t know why this is unwanted nowadays.
Instead of supporting and renewing textual config use there is a noticeable aversion from many responsible openhab maintainers…
In my case: exactly because of the issue presented here. Misconfigurations are hard to find and sometimes result in unpredictable behavior that looks like a bug.
in UI it’s also possible to misconfigure items and things. Tried that for a time in OH 2.2 with PaperUI…
I never had so much inconsistency with my textual config.
And in general it wouldn’t be easier to configure a mqtt device in UI because you have to link the channels manually and understand which datatype the mqtt-topics are.
Only the uppercase error would’ve been prevented. But there’s no automatic detection…
I’ll chime in and agree with Jan here. It’s because of threads like this that I’ve stopped messing with support for text based configs. The amount of time spent hunting down syntax errors like this which are impossible to make in the UI is dwarfed by the amount of time lost in converting from text based to managed or clicking to create a few things.
There are lots of great techniques and tools for creating lots of Things and Items in MainUI so it’s not like one has to use the mouse to click/create a dozen similar MQTT Things. You can create the one and then copy/paste/edit that one. Most bindings automatically discover the Things anyway so it’s just a few bindings where you have to do that anyway (MQTT being one of them). If you’ve already some working .things files, as Jan pointed out, it’s a simple matter of querying for the JSON and posting that back through the REST Docs.
Items can be imported in bulk from the .items files in one go, though if you want to use the Semantic Model I recommend using “Create Equipment from Thing” instead as it will be less work in the long run.
There are indeed still a lot of use cases where text based configs make sense and it will remain supported. But the average user will save lots of time and have a smoother experience overall if they use the UI, especially for Things (which has been the official recommendation since OH 2.2ish) and Items.
For those who do insist on using text based configs, please at least create one Thing through the UI and look at the code tab when having trouble. The YAML properties are the exact same ones, case and all, that will be used in the .things files.
MainUI is a complete rewrite and if it were as poor as PaperUI was I would not push its use like I do. But it’s really quite good. It’s amazing what four years of development can accomplish.
While it is indeed possible to misconfigure something in MainUI, it is not possible to create syntax errors like occurred here. You might have the wrong IP address here or a messed up transformation configuration over there, but you’ll never have a problem like using ‘On’ instead of ‘on’ for a parameter name.
You have to do that anyway in text files too. But in the UI you don’t have to hunt down all the parameters for a given Channel type and make sure you get the names correct including case and all that sort of thing. It’s all presented there to you as a form with each field more or less documented on how each field is used and what needs to go into it. One hardly ever needs to look at the docs or postings on the forum or anything like that. They just need to see what’s presented in MainUI and most of the time what and how to configure the Thing is apparent and obvious.
And MainUI won’t let you accidentally, for example, link a Number Item to a text Channel or do other impossible things that can be done in text files.
I used to be a text file proponent. But over the years as I’ve spent more and more time on my own system and even more time helping people on the forum I’ve come to the informed opinion that unless you fall into a few very specific cases (e.g. maintaining multiple OH instances with fragments of configs parceled out and reused in each or using some specific bindings like modbus or KNX) you are doing yourself a disservice by using text based configs. You are waisting your own time and the time of those on github and the forum who need to be called upon to help fight syntax errors that simply cannot occur in the UI.
That’s why I and a number of the maintainers push UI over text based configs. It’s a better use of everyone’s time and it’s a better experience for you the end user in the long run.
1 Like
I have to search on the forums for this…
Is there a documentation how to do this? maybe I’ll give it a try…
what prevented me from trying this was the fact that I read multiple times about inconsistency with using a mixed configuration.
Yes and I like the mainUI very much but way back while using PaperUI I had problems with already configured items which appeared in the inbox and stuff like that - this made me a bit afraid of a database-based config… maybe the db-handling is a lot better today in mainUI…
in most cases VSCode does a lot highlighting, auto completion etc. and I would say most of my topics are “but how do I” and not “why isn’t this working” topics.
and most of the time my openhab is running without errors, only while adding new things or struggeling with rule writing there were some problems… So there’s more work to do than effort to get for me personally.
by the way, what is the future of script rules, I have some jython rules beside my dsl-rules
and read your using UI based JS?? rules nowadays… what language/syntax is used? is this also yaml based?? To find a better solution for my rules is more important to me at the moment, I would like to dig into something “futureproof” where the effort is worth it…
I know
I barely agree but on the other side most of my problems are rule related and not with using items or things - nowadays openHAB is extremely well documented - I can think of other times where finding solutions for my problems was more like a “kid’s paper chase”…
In MainUI go to Settings → Items → + icon to add Item
You can paste part or a whole .items file there to import. You can also just type in a bunch of new Items there, it checks the syntax as you type.
You can also get to this screen from Developer Tools → Add Items from Text Definition
This is covered at a high level in the Getting Started Tutorial: Semantic Model | openHAB
Definitely go through that tutorial.
You’re not using a mixed configuration. You are creating an example which you can then immediately delete if you don’t need it any more. All of your functional configuration would be in .things files in that case.
The problem was when there was a Link between an Item and a Channel and one deletes the Item or the Channel without first deleting the Link. This is harder to do now and in the rare cases where it might occur (usually because you are doing stuff with the REST API manually instead of using MainUI) there are commands in the Karaf console that can clean that up.
Future proof doesn’t really exist. Everything will stop being supported at some point. The currently built in JavaScript (ECMAScript 5.1, Nashorn) is probably first to go. It’s already deprecated in Java 14 and no longer exists in any version of Java after that. Java 14 is nearing end of life so OH will have to move. Jython doesn’t really have upstream support any more so at some point it will break and we won’t be able to fix it.
I am currently using the JS Scripting add-on and creating 100% UI based rules. It’s JavaScript (ECMAScript 2021 to be precise) and with the helper library that it comes with it’s way more powerful than Rules DSL but just about as easy to use.
If you are not a programmer, I recommend using Blockly. A lot of users are converting their old Rules DSL rules to Blockly actually. It’s easier to understand and build for most and has far more capabilities.
But even before that I recommend looking at the Marketplace. Why code a rule when you can just install and configure it? There is a growing library of rule templates, some very low level (Debounce [3.2.0;3.4.9]), some simple (To Today [3.2.0;3.4.9)), and some a complete suite (Scene Control Suite - Scene Modification).
Nothing is YAML based. The only place you see YAML is in MainUI which converts JSON to YAML because YAML is way easier for a human to read and understand. But OH stores and internally uses JSON. But you as the rules coder never really have to look at YAML unless you want to (e.g. to duplicate something using copy/paste/edit) or you need help from the forum (we like when people post the YAML instead of screenshots).
You’d code in the web based editor which has syntax highlighting and some code completion and a lot of the stuff you are used to from VS Code too. This is one of my JS Scripting Script Actions.
This full rule appears in MainUI as
But that isn’t really helpful. To see the YAML translation of the JSON that actually makes up the rule click on the Code tab.
configuration: {}
triggers:
- id: "1"
configuration:
itemName: HomeEnergyMeter_ElectricmeterkWh
type: core.ItemStateChangeTrigger
- id: "2"
configuration:
itemName: HomeEnergyMeter_Access
type: core.ItemStateChangeTrigger
- id: "3"
configuration:
itemName: HomeEnergyMeter_Rate
type: core.ItemStateChangeTrigger
conditions: []
actions:
- inputs: {}
id: "4"
label: Calculate the power bill and update the Item
configuration:
type: application/javascript;version=ECMAScript-2021
script: >
var logger = log('Power Bill Estimate');
var curr = items.getItem('HomeEnergyMeter_ElectricmeterkWh').rawState;
var rate = items.getItem('HomeEnergyMeter_Rate').rawState;
var access = items.getItem('HomeEnergyMeter_Access').rawState;
var estimate = (curr * rate) + access;
items.getItem('HomeEnergyMeter_CurrentBillEstimate').postUpdate(estimate.toString());
logger.debug('Calculated bill = ${}', estimate);
type: script.ScriptAction
Here’s a Blockly Script Action.
1 Like
thanks… I managed to import my .items files before reading your post… wasn’t hard to find.
now I’m stuck using the rest api to re-add my things
I saved the json to a file using:
curl -X GET --header "Accept: application/json" "http://127.0.0.1:8080/rest/things?recursive=false" -u openhab3 >> things.json
now I’m unsure if i should restart openhab when items are already in db and I removed the .things files - don’t want to mess up the channel linking in some way
and for the question of rules I’ll have a look at JS Scripting - maybe a good approach
Everything is done based on the UIDs of the entities. For an Item, the UID is the Item’s name. For a Thing it’s the Thing ID.
As long as your Thing retains the same ID and your Items retain the same names, no problems should occur. The Link will be temporarily orphaned but as soon as the Thing comes back the Link will be correct.
So I would remove the Thing from the .things file and then add it back through the REST API. Note that as seen above, sometimes OH doesn’t pickup and apply changes to .things files immediately so pay attention to the logs as you work. You’ll get an error if you try to recreate the Thing when OH thinks it still exists.
If you do run into trouble, a backup of the JSONDB gets made automatically when you make changes in $OH_USERDATA/jsondb/backup. You can go back a few steps if you need to.
And after everything you end up with some orphaned links, we have ways to deal with that now too. But I doubt that will happen. Just be careful to maintain your current Thing IDs and you’ll be fine.
thanks! What would the import look like in ssh console? …and can I import the whole things.json in one attempt?
in the rest api docs I’ve found a few examples only… or should I use the UI’s webapplication?
I haven’t found a good howto in the forums…
You are referring to the Things?
You have to use the REST API Docs. Under Developer Tools → API Explorer go down to the “things” section.
-
If you want to do it all in one go, use the “get all things” call to get a JSON dump of all of your Things. Copy that JSON off somewhere. There’s a nice pair of buttons to copy it to the clipboard or download the file.
-
Then remove your .things files and verify that all the Things are gone (you can look in MainUI or see if the call made in step 1 returned an empty JSON.
-
Unfortunately you can’t create more than one Thing at a time. So you’ll have two create them one by one. Copy the JSON for one Thing (you can tell by paying attention to the { } and indentation where one Thing starts and ends). It’ll look something like
{
"channels": [
{
"linkedItems": [
"vNorns_Status"
],
"uid": "network:pingdevice:norns:online",
"id": "online",
"channelTypeUID": "network:online",
"itemType": "Switch",
"kind": "STATE",
"label": "Online",
"description": "States whether a device is online or offline",
"defaultTags": [],
"properties": {},
"configuration": {}
},
{
"linkedItems": [],
"uid": "network:pingdevice:norns:latency",
"id": "latency",
"channelTypeUID": "network:latency",
"itemType": "Number:Time",
"kind": "STATE",
"label": "Latency",
"description": "States the latency time",
"defaultTags": [],
"properties": {},
"configuration": {}
},
{
"linkedItems": [],
"uid": "network:pingdevice:norns:lastseen",
"id": "lastseen",
"channelTypeUID": "network:lastseen",
"itemType": "DateTime",
"kind": "STATE",
"label": "Last Seen",
"description": "States the last seen date/time",
"defaultTags": [],
"properties": {},
"configuration": {}
}
],
"statusInfo": {
"status": "ONLINE",
"statusDetail": "NONE"
},
"editable": true,
"label": "norns status",
"configuration": {
"hostname": "100.107.66.87",
"refreshInterval": 60000,
"retry": 1,
"timeout": 5000
},
"properties": {
"icmp_state": "Java ping",
"dhcp_state": "off",
"presence_detection_type": "",
"arp_state": "Arping tool by Thomas Habets",
"uses_ios_wakeup": "Yes"
},
"UID": "network:pingdevice:norns",
"thingTypeUID": "network:pingdevice",
"location": "Admin"
}
That’s a Network Binding Thing.
-
Go down to the POST REST API endpoint and submit it. I think it will ignore the entries that it doesn’t require here like the “linkedItems”. If not you may have to remove those. The example in the form shows what fields it expects.
-
Repeat 3 and 4 for each Thing
When done all your Things will have been imported as managed.
However, I might recommend that for those Things that can be automatically discovered consider going to the Inbox after removing all your old Things. Then for each binding that supports it, scan for the devices and accept them. You have this one opportunity to change the UID of the Thing before accepting it so make sure to choose the same UID that the Thing had before. Repeat for the other bindings.
This will ensure that your Things have all the latest parameters and capabilities. Then you only need to manually post the Things that cannot be discovered automatically.
yes you’re right
as I wrote, I already exported them to a things.json file via curl…
Ah ok, already tried a bulkimport in UI but got errors - now I understand why
I will give it a try tomorrow…
I’m a bit afraid that I mess it up by manually typing in my thing UIDs
I think I will try importing them first if this ends up without errors I’m fine
…otherwise I’ll try the autodiscovery
Thanks so much! I’ll go to sleep it’s midnight in Germany now…
maybe I write a little Tutorial after getting this done tomorrow
1 Like
it’s done
All items and things are imported or added to UI - except a few network ping devices…
Couldn’t import most things, had to add them manually - 8 hours of pain - but it’s finally done!
Was a bit fiddly to get all the UIDs out of my files - but it seems all channelbindings are still intact.
Will restart OH now and see what the logs have to offer
Thanks Dan and all contributor for this nice and constructive conversation that help beginners like me to find their way between UI and text definition.
I just want to point out some nice tools developed by @ysc that helps to automate some action using the rest API form YAML files. ( see [Tutorials & Examples/Solutions] Ohadm - A simple script to manipulate openHAB objects and sync them to YAML files). I used this to duplicate and reimport things and item previously created using the UI.
1 Like