Migrating ZWave to OH3

Glad to have found this thread. I’d like to play with OH3 on a separate piece of hardware without permanently bringing down my OH2 instance. Does the z-wave node number assignment stay with the transceiver? That is, will node3 in the OH2 system still be the same device with the same ‘node3’ designation in the OH3 system if I just move the USB dongle?

1 Like

I was pretty certain this was one of the “actions” parameters which end up in this list but apparently not…

image

How does this work again @chris?

It’s just a standard command with type REFRESH - it’s the same for every bind (assuming the channel supports this command of course).

        if (command == RefreshType.REFRESH) {

1 Like

Just as a hint, I have created manual configuration of things and items. It can be as a copy paste to OH3 and works like a charm. It requires some investment to do. But as I have 100+ things in my system and I managed to move them in a weekend it is not too hard to do.

You mean copy-paste for every thing and item? or do you refer to the ‘Add Items from Textual Definition’ action ? That AFAIK only works for items not things.

I have a generic export/import screen for the developer tools in the roadmap for 3.1 or 3.2. You could generate either individual files with several things, items, rules, pages, widgets or could export them as a package in a single big YAML array. Then you can modify it and reimport it the same way.

It could be interesting to have “packages” like these shared in the community so when you import them you get all you need, items with rules directly interacting with them, widgets and pages etc.

7 Likes

Does this mean you could export items in the same format they appear in a .items file, make changes, then return them to the import screen to make changes?

If so, that would be unbelievably helpful!

1 Like

Yes yes yes please yes! I’ve wanted something like this forever.

3 Likes

I’ve always been a friend of such a functionality. Although i remember someone (or two) told us, that noone requests such a thing and it won’t be usefull anyway.

I strongly support these “yes”. All the four of them! :slight_smile:

Not to tease you even more, but we could even make use of the same expression parser as the one used in widgets, and have the same structure with “props” so you can parametrize your package prior to applying it.

Something like:

props:
  parameters:
    - name: prefix
      type: TEXT
      description: The prefix for the entities created
    - name: desiredTemp
      type: NUMBER
      description: The desired temperature
slots:
  items:
    - component: Item
      config:
        name: =props.prefix + '_CurrentTemp'
        type: "Number:Temperature"
        tags: ["Measurement", "Temperature"]
        ...
    - component: Item
      config:
        name: =props.prefix + '_HeatingControl'
        type: Switch
        tags: ["Switch", "RadiatorControl"]
        ...
  rules:
    - component: Rule
      config:
        UID: =props.prefix + '_switchradiatoron'
        name: ='Switch ' + props.prefix + ' radiators on'
        description: Switch on the heating when the temperature is too low
        triggers:
          - configuration:
              itemName: =props.prefix + '_CurrentTemp'
            type: core.ItemStateUpdateTrigger
        conditions:
          - configuration:
              itemName: =props.prefix + '_CurrentTemp'
              operator: <
              state: =(props.desiredTemp - 2)
            type: core.ItemStateCondition
        actions:
          - configuration:
              itemName: =props.prefix + '_HeatingControl'
              command: ON
            type: core.ItemCommandAction
    - component: Rule
      config:
        UID: =props.prefix + '_switchradiatoroff'
        name: ='Switch ' + props.prefix + ' radiators off'
        description: Switch off the heating when the temperature is too high
        triggers:
          - configuration:
              itemName: =props.prefix + '_CurrentTemp'
            type: core.ItemStateUpdateTrigger
        conditions:
          - configuration:
              itemName: =props.prefix + '_CurrentTemp'
              operator: >
              state: =(props.desiredTemp + 2)
            type: core.ItemStateCondition
        actions:
          - configuration:
              itemName: =props.prefix + '_HeatingControl'
              command: OFF
            type: core.ItemCommandAction

This would replace the rule templates that honestly never became a thing.

2 Likes

As the UI guru, can you take a peak at this post. I probably should have noted it in the OH3 RCI thread, but wasn’t sure at that time. As it have fixed all the other issues from OH2.5.10 to OH3, it is probably related.

Sitemap "setpoint" formatting in OH3

PS - No worries, if you are too busy

Yes, it works for .things and .items both. I do not remember form witch version but textual configuarion works for Zwave things as well. You can search back in Zwave threads. This is the easiest way I think.
It works on my system. It took some time to create it for so many things but it worth. In case of server issue recovery is easier as well. The only thing is I still at 2.11 is that my Phyton rules are not running, but OH3 is ready now on my server.

You misunderstood. Yes you can provision .things and .items but that does not convert these into the internal DB format which is what you will have to do if you want to maintain them in UI from there on.
That’s what the ‘Add Items from Textual Definition’ button in the UI does.
But for items only, not for things.

Sorry, I got it now. I saw that maintenece of things and items have more possibility then before and textual configuration provides also higher freedom then I had when I started to use Zwave. But the good in that system is that make it and forget it, means no need of change or maintenence if the original set up was done properly. So only change of my Zwave set up was that I created .things file, nothing else. I use Fibaro, Aeotec, Philio and Danalock brands.

This is Basic UI right? I’m not familiar at all with this code.

Yes BasicUI, but if this is not your area, nevermind.

Bob

1 Like

I’m having a big problem figuring out how the Mios Item Generator works.
Can anybody kind of give me a play-by-play to setting up this binding?
I want to have all of the devices result in populating my items file in Openhab.

Despite having read this a few weeks ago, I forgot to copy the security key over to my new OH3 installation. So, I did this step after adding my ZWave door lock, and it won’t accept commands to the lock. The log says:

NODE 5: Command class COMMAND_CLASS_DOOR_LOCK not found

I’m directly toggling the channel through MainUI, so it’s not an item problem.

I tried restarting OH, removing/discovering the device, removing/re-adding the controller, uninstalling and reinstalling the binding, and deleted the existing ZWave XML entry for the node. However, I can’t get the behaviour to change no matter what I do.

Am I missing something obvious?

I had a similar issue with 2.5. The only solution I found was to physically exclude the door locks from my zwave stick and OH. In my case, I had to pull the stick from the computer, put the stick in exclude mode and stand by the lock to exclude from the door lock. I then re-included after plugging the stick back in adding the lock again via OH. Security for locks is very touchy from my experience.

If distance isn’t an issue between your controller and the lock you may not need to remove but you will. have to physically exclude from the lock.

This will happen if you don’t set the key. The binding will discover the features of the device during the interview, and as the key is wrong, it won’t discover the lock class. That is normal (it’s secure - right :slight_smile: ).

To fix this, you’d need to do the interview again after setting the key.

So, I’m not really clear what has been done, and in what order. If you’ve excluded and reincluded, then the device may either be using a new key, or it may not be securely included any more - both of which would give you the same issue as you started with.