Where do you define users in OH3?

Setup, Configuration and Use Beginners
13

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.)

14

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.

15

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. :smiley: 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.

16

I would remove jdbc-mysql, especially since it is complaining.

Oh, for some reason I thought you had OH3 on different hardware. :frowning:

17

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.

18

Well during testing I had it on a virtual machine, it worked great! :smiley: 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.

19

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!

20

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. :smiley:

21

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:

image
image1160×419 55.4 KB

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.

  1. Someone physically flips the zwave switch
  2. OH 1.x gets that event and updates Item1.
  3. The MQTT event bus publishes that update to a well known topic for Item1.
  4. OH 3’s MQTT configuration subscribes to the topic and based on the topic path determines it’s an update (as opposed to a command) for Item1 and updates Item1 accordingly.

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.

  1. In OH 3 something sends a command to Item1
  2. The MQTT Binding publishes the command to the well known topic for Item1 commands (updates and commands go to different topics).
  3. The MQTT eventbus config in the MQTT 1 binding sees the command on the topic and commands Item1 with the published command.

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.

22

Do you have a lot of ‘stuff’ on it? Scenes, plugins etc? I completely stripped mine bare - effectively factory reset it - so that now it is just the relay between openHAB and my Z-Wave devices.

No exaggeration: it has been rock solid since 2014, survived a number of house moves and power outages, and just continues to quietly blink happily in the corner.

So I’m the complete opposite to you: I wouldn’t move to OH3 until I found a way to integrate my Vera, as it’s been so reliable! Not helpful, I know - sounds like you’re having terrible luck!

23

Is that do-able via the UI, or only via config files? My plan was to use the UI for things & items, and config files for rules. There was a reason for that decision, but off the top of my head I can’t remember what it was.

24

No. Like you mine is almost devoid of everything except its zwave network info and the oh interface. It’s always been really sluggish since day 1; back when I would ssh into it and tail log files, it’d often have ten, fifteen seconds between updates and/or just randomly kill the ssh session with no rhyme nor reason. It’s a vera edge, and I suspect it’s just dramatically under-spec’d for the job it’s being asked to do.

The reason for the reboots is that without it, if OH sends it a command there’s a 25% chance it’ll get ignored completely. There’s another 25% chance that it’ll take forever (30s) to execute. The rest of the 50% is instantaneous execution, so I know the hardware is capable of doing it, it just… isn’t. (Suspect it’s because of memory leaks / garbage collection happening and just being unlucky with timing. Not worth the time/effort to find out.) But if I reboot it every day, it never ignores commands and only about a 10% chance of delayed execution but even then it’s down to a live-able-but-could-definitely-be-better 10 second delay.

25

On OH 1 you know the answer, there is no admin UI. You’ll have to configure the MQTT binding to enable the event bus in openhab.cfg. Everything in OH 3 except for defining persistence strategies (i.e. .persist files) and a few other things (creating new users, populating the Exec binding’s whitelist, custom Ephemeris configs, etc.) is doable through the UI.

So you have your choice of how to define things. Everything but rules done through the UI is definitely possible. Personally, I’m even putting my rules in the UI. I like the when/but only if/then structure of the rules. It makes it easy to define when certain rules are allowed to run separately from what the rule does when it runs. I like the break between those but that structure is not possible in text based rules. You have to implement the conditional as if/switch statements at the top of the rule.

26

You misunderstood my question. Can you change a thing’s core definition from the UI? Can you change it from being a mqtt thing to a zwave thing?

27

This is impossible and does not make sense imho.

28

No but why would you? Just create a new Thing and update the links to the Items. Things are inextricably bound to the binding. You can’t take a Thing from one binding and turn it into a Thing for a different type of binding.

You can’t do that through .things files either.

1 Like
29

If all the names are going to change when going from mqtt to zwave then I don’t understand why you’d do it in the first place. I guess you could do a global search and replace, but… Ugh.

30

The Links will change. The Things will change. The Items will not change and Items is what OH uses everywhere else. Your UIs wouldn’t change. Your Item configs wouldn’t change. Your Rules wouldn’t change. Your Persistence wouldn’t change.

All the real work in OH is done with the Items. And with this approach the Items remain unchanged. All that changes is the link. When you change the link, the same Item will go from MQTT to Zwave and everything else remains unchanged.

And yes, this is a little more work to set up. Eventually you’ll need to change the links on the Items. But you are doing this to gain the ability to work on the OH 3 config while leaving OH 1 up and running. You can create all your Zwave Items, Rules, sitemap, pages, persistence and all the rest in OH 3 now and verify it’s working the way you want without having to deal with the problem with the Zwave binding until Chris can get back to you and without needing to wait for a time when it’s OH to bring OH 1 offline.

Only being able to work on the OH 3 config at night when the family is asleep. Ugh. Not being able to make any progress at all on the config because of a problem with a binding. Ugh.

31

I’ve opened a github issue since this looks like an internal zwave binding bug. Debug logs, and even a zwave radio sniff while it was going on are available there. (Yes, I have a zniffer & know how to use it. Yes, it’s useful. No, it’s not as useful as often as you’d think.)

As for mqtt, I see what you’re proposing, and if I had to be off of oh1 with a fixed date I’d be following your plan. Thanks!

32

I cannot create a user here:
Whenever I put in something and press create, the mainUI erases everything and says:
please try again (on 3.0.1)