Hello, new to openhab3, long time openhab1 user. (Never used openhab2.)
I’m trying to set up the vscode editor. In the github docs, it says for OH3 you need to make an api token for your user. But it doesn’t tell you where nor how to do that.
I have the web admin user, but for the life of me I can’t figure out where you can even create regular users, let alone how to generate API keys for them. And the documentation doesn’t seem to mention users at all, so I’m… stuck hard.
Thanks in advance!
Users can be created on karaf console, but you don‘t need another user for using API tokens.
When logged in as admin, just press the admin symbol again and you will find the menu to create tokens.
Thanks guys, I’m throwing in the towel on OH3. Sorry to waste your time, but I just don’t have the effort to put together a 10K puzzle jigsaw at this point. The docs being nonexistent for oh3 really doesn’t help and I’m burning through my accumulated WAF faster than an oil rig on fire.
(I can’t even get binary state zwave devices working. Thing defined, channel defined, item defined all via UI, changes state on-off-on-off in the UI, doesn’t send out anything via zwave. After the 50th thing like that in the past eight hours, I’m DONE.)
Moving from OH 1.x to OH 3 is not going to be a simple upgrade. Almost nothing that is supported in the OH 1 config is going to be usable as is.
You’d be far better off migrating to OH 2.5 where you can at least continue to use your existing bindings and such and migrate over at a much slower pace. I did the 1.x to 2.x migration in an afternoon, and that was with taking notes as I went so I could write the migration tutorial.
Only when you’ve fully migrated to OH 2.5 and replaced all your OH 1.x bindings with 2.x bindings would it be wise to migrate to OH 3.
The other option is to start over from scratch with OH 3. But that’s going to take a good deal more work just to get to the same place you are now.
In either case, you would want to do this without taking down your production OH instance until you are ready.
Or you can stay on OH 1.x until you can’t run it any more.
As for the docs, well the few of us who are doing anything about writing docs are doing the best we %&^*ing can. We need help an no one steps up. But there is no end to the complaints. Complaints are easy I guess. But the docs for OH 2 and OH 3 (since they are 80-90% the same since they work the same) are a hell of a lot better than the old OH 1.x wiki ever was.
While not yet complete (I’m stuck on the Pages part) the first part of the [Getting Started Tutorial] should cover most of the first steps to getting started. Did you try to go through that? Do you have any suggestions for improvement? Or are we just “the docs suck.”
I’m at the “zwave binding wouldn’t execute simple on/off commands” for three different devices from three different manufacturers, so I tapped out. I had it debug logging and the binding would receive the commands and the UI would update, they’d just never go out over the radio and make things happen.
I’ll be trying oh 2.5.whatever as a last ditch; hopefully whatever has gone wrong in the oh3 zwave binding (which seems severe) doesn’t also affect the 2.5 binding.
I’m looking at a complete re-write no matter how you look at it, so whether I went to oh2 or oh3 didn’t really matter much. (The only binding that isn’t going to make the transition is mios, and once I get off of oh1 I won’t need mios anyhow.) I have a lot of institutional knowledge with oh that I don’t want to throw away. But if I ever were going to switch horses now would be the time so I’m in reevaluate mode since I couldn’t even get a minimal oh3 config to work.
And unfortunately due to how zwave works, doing it without taking down the production interface isn’t possible. It basically functions as a serial port; one process can read/write to it, and that’s it. So I’ve been having to take my existing oh1 up and down like it’s riding a trampoline testing various things.
I trust you’ve gathered logs and files an issue. The Zwave binding is one of the most commonly used binding and I’ve seen no reports of issues like theses reported. I myself use it and almost all of my devices are simple on/off switches. I was surprised at how easily I was able to migrate for Zwave actually. Even my locks worked.
If you where coming from OH 2 there would be a way to do it using the Remote openHAB binding. You could spin up an instance of OH 3 and build up it’s config little by little using that binding to mirror the Items. But OH 1 didn’t really have a good REST API for that sort of thing.
You could set something similar up using MQTT with the event bus though.
Also, Zwave really depends on the database which has undergone a ton of updates in the years since the last OH 1 release. I don’t know if the db is backported or not. It might be worth a look to verify that your devices are still in the db and the info is correct.
All I can really offer is if you are expecting to sit down and recreate your current system in an afternoon you are seeing yourself up for failure. Your institutionL knowledge, while not completely worthless, is missing three or four years worth of continued evolution and development to the core and add-ons. I wonder if it might be more of a hindrance than a help really because there is so much IH 1 type stuff that we simply don’t do it that way any more.
And a misunderstanding or misconfiguration could be the root cause of your current problems. Without specifics who is to say.
Did you reach out to the community here? The developer here tries to be very helpful. He is extremely busy right now preparing for an international move.
He is one big reason why I was able to move to OpenHAB from a different system.
Yep. I’m not sure how Chris wants to handle it so I’ve written him offline. I love Chris and have worked with him quite a bit before, so I owe him that much at least.
Since I’m up in the middle of the night I decided to do a clean recreation for log purposes; split out zwave into its own file and set the log level to trace. The problem is that zwave initialization keeps dying and dying and dying (and as a result my controller keeps going online-offline-online-offline-online-offline), so no zwave commands actually make it out the stick. Device initialization is taking upwards of 20 minutes because I think it’s just dying on each device, restarting, going to the next one, dying again, restarting, going onto the next, repeat ad 150-times or so.
Anyhow I at least owe Chris that much, so I can keep trampolining my oh1/oh3 setup up/down at odd hours to get this dealt with. I sent him an email to see the vector he wants to take on this.
I’m not expecting that. (That’s entirely unreasonable, especially for a system with as many rules as I have.) But what I was expecting was to be able to get some things defined in the gui and manually toggle zwave switches in an afternoon and have things, you know, actually go out the radio in good time and turn on and off.
That’s pretty much impossible at this point. All I’ve done is point it at the stick, thing discovery happened, and then using the UI I created items from channels and assigned them to groups. Oh and made the world’s dumbest/cleanest sitemap with exactly three groups on it. (No need for complexity or rules, just show me the base toggle switches and dimmers at this point!)
…d’oh.
That sounds like invalid addons in the addons.config file causing addon restarts every minute. A common culprit was restdocs because its path changed.
What bindings are you installing to recreate the issue? Are you testing on OH3 or OH2.5.x?
Where does this file exist? I can’t seem to locate it.
Astro, exec, jdbc-mysql, and zwave at the moment. I haven’t touched exec or mysql at all. I did do a perfunctry config of astro but didn’t get to defining items yet. OH3 is complaining about jdbc-mysql because I haven’t gotten to configuring it. That makes sense but shouldn’t cause the zwave binding to die.
OH3.1 snapshot #2115 from 2021-01-03, though identical behavior was observed with OH3.0 stable. (That’s why I went to devel snapshot, hoping it was a bug that’d already been fixed. Natch.)
I always forget. It is down in the userdata tree. If changing, stop OH first. Also check addons.cfg in your CONF area.
Try removing that to see if things settle down. Early on, zwave interfered with astro until Chris fixed it.
Well I’m not sure what it’s supposed to look like, but here’s the complete contents:
$ more addons.config
:org.apache.felix.configadmin.revision:=L"9"
binding="zwave,astro,exec,http,network"
package="standard"
persistence="rrd4j,jdbc-mysql,mapdb"
service.pid="org.openhab.addons"
ui="basic,habpanel"Guess I forgot about the http, network, and mapdb bindings. It’s been a whirlwind. 
Nevertheless, nothing looks crazy in there to me.
$ more addons.cfg
# The installation package of this openHAB instance
# Note: This is only regarded at the VERY FIRST START of openHAB
# Note: If you want to specify your add-ons yourself through entries below, set the package to "minimal"
# as otherwise your definition might be in conflict with what the installation package defines.
#
# Valid options:
# - standard : Standard setup for normal use of openHAB
# - minimal : Installation of core components, but no UIs or other add-ons. Use this for special headless setups.
# - demo : A pre-configured demo setup which can be used for demonstration.
#
# See https://www.openhab.org/docs/configuration/packages.html for a detailed explanation of these packages.
#
package = standard
# Access Remote Add-on Repository
# Defines whether the remote openHAB add-on repository should be used for browsing and installing add-ons. (default is true)
#
#remote = true
# A comma-separated list of automation services to install (e.g. "automation = groovyscripting")
#automation =
# A comma-separated list of bindings to install (e.g. "binding = knx,sonos,zwave")
#binding =
# A comma-separated list of miscellaneous services to install (e.g. "misc = openhabcloud")
#misc =
# A comma-separated list of persistence services to install (e.g. "persistence = jpa,rrd4j")
#persistence =
# A comma-separated list of transformation services to install (e.g. "transformation = jsonpath,map")
#transformation =
# A comma-separated list of UIs to install (e.g. "ui = basic,habpanel")
#ui =
# A comma-separated list of voice services to install (e.g. "voice = googletts,marytts")
#voice =Which, astro or jdbc-mysql? I’ll have to wait until I get another window I can take down oh1, likely late tonight.
I would remove jdbc-mysql, especially since it is complaining.
Oh, for some reason I thought you had OH3 on different hardware. 
Assuming a Linux install, /var/lib/openhab/config/org/openhab/addons.config. This is the file that gets updated when you modify stuff through the UI or it gets overwritten if you modify the contents of /etc/openhab/services.
Since TheKorn is comming from OH 1, I’m not sure that would be the problem here. For one, there was no REST API Docs in OH 1.x nor was there an addons.cfg file. Everything was in a single big openhab.cfg file.
Also, there would be log statements indicating the failure to install, right?
I agree, the symptoms do seem like that sort of thing could be going on, but given where he’s coming from I don’t think that would be the case here.
Agreed, it looks pretty normal and nothing is listed that doesn’t exist which would cause the looping problem Bruce mentioned.
If you intend to continue on I really do think it will be worth the effort to configure the MQTT event bus config on the OH 1.x instance to mirror the Items on OH 3 and be able to run OH 3 in parallel. That way you don’t have to bounce OH 1.x to work on it. And you can continue to make progress in other areas like rules and working with the other bindings while this Zwave problem is diagnosed and fixed.
I’ve no doubt that the problem can be fixed, one way or the other but in the mean time you can continue to make some progress as well.
Well during testing I had it on a virtual machine, it worked great! It was only when I shifted over to real hardware that I had problems.
I’m a little confused as to this suggestion; who would be hitting the metal, OH1 or OH3? Even though mqtt is in the cards, that’s a ‘next month after the shakedown’ item as originally planned. I’m also a little reticent because whenever Chris comes up for air, it’ll be a step I have to undo in order to properly test a fix to the zwave binding. (Assumption, but not a wild one I don’t think.)
I can continue running 1.8 for now without too many problems, it’s just that adding new hardware has been a headache and I really really really want to pour gasoline all over my Vera. (My vera is handling all the zwave security stuff under oh1.) It’s not as if I need to be off of oh1 next week, it was just I had a bunch of time off this week so was a good time for me to ride the canoe over the waterfall. Since I didn’t hit that mark, no longer a three alarm fire.
I have a Vera Lite, and am using it successfully in OH3 using the HTTP binding.
I was also using the v1 MIOS binding in OH2, then you’ll see in the linked thread that I tried some Jython classes, but ultimately the HTTP binding is just too easy!
Thanks, that looks reasonable. Only real problem is that I outright loathe my vera; I have OH reboot mine every 24 hours just to make it tolerable. The only thing that’s kept it from contributing to global warming has been that I didn’t want to spend the effort to upgrade off of oh1. Once I get [a working] oh3 then my vera’s entire reason for existence will cease to be, and so will it.
Until such time as this particular problem is solved, OH 1 would be the one hitting the metal since for zwave it’s the only one that works. Then you can go focus on other stuff, get some wins under your belt and make some progress. Only when you are trying to solve this zwave problem on OH 3 would you need to turn off the OH 1 instance.
Yes, but not a big step. All you’ll have to do is change the links on the Items from the MQTT Things to the Zwave Things. Once it works you can remove the MQTT Things. Or you can have two sets of the Items in OH 3, and once you get it sorted eliminate the MQTT ones. Though that would mean different names which will have impacts on the sitemap and rules and such.
Stage 1 would look something like:
OH 1 continues chugging along with the zwave stuff and anything else you haven’t moved over to OH 3 yet. Then as stuff moves over you remove the links from the Generic MQTT Things and link the Items to the Things from the actual bindings. At that point OH 3 has taken over for OH 1 at that point.
A flow would be something like the following.
Note that step 4 sounds complex but it’s just a few lines of rule code really.
The flow in the other direction would be something like the following.
This will let you do all sorts of configuration in OH 3 such as creating the UI, porting rules, sitemaps, etc. without needing to take OH 1 offline. OH 1 only needs to be offline when you are testing or migrating a piece of shared hardware to OH 3.
You won’t be able to get away from ever stopping OH, but you will be able to do the bulk of the work while OH 1 continues running.
And while I showed the arrows as two directional, you could make them unidirectional (i.e. OH 3 gets the changes from OH 1 but commands and updates from OH 3 do not go back to OH 1).
And of course, if you need help with any of this sort of stuff, just ask and I or anyone else will be happy to help you debug and get things working.
