Zwave parameters rejected in 3.0M4

Setup, Configuration and Use Runtime
1

Hi, I’m on OH3 M4. Has anyone experienced ZWave device configuration parameters being rejected? example: Fibaro FGD211 Dimmer. I want to set Parameter 20 to 135 to properly dim LED bulbs. This worked fine in OH2 (and in Vera!). Now OH3 objects and says no and stubbornly resets the value to MINUS 121! I tried it both in the text window setting and in the Code tab. My 135 won’t stick!
There are other strange parameter behaviourisms with Polling periods for Battery devices. Battery devices SHOULD NOT be polled. The text window stubbornly defaults to and fills in 86400 and I need the code window to overrule this with a ‘null’.

1 Like
2

It has been recommended to use a newer snapshot. M4 appears to be a broken release.

3

Oh dear…thanks for that quick reply. Maybe I should revert to my stable 2.5.10 until the dust settles on all these Milestone releases being broken/fixed…

4

I chose to stay on Milestone 3.

5

I thought I was being modern by chasing the latest milestone… :roll_eyes:… I’ve spent a whole day migrating over from 2.5.10… how did you know to stay with M3 :face_with_raised_eyebrow: :upside_down_face:

6

Hi Denis, Do you have any tips on migrating, as I want to do the same thing?

7

I chose M3 instead of a later snapshot though.

8
9

Hi Nigel,
I’m not sure it’s worth it at the moment (if you have a nice stable working system) given the time one can easily spend trying to get some details to work only to hear later that the particular milestone is broken… :roll_eyes:
OH3 messed up some Zwave device config parameters on me and I had to fix them up after reverting to my stable 2.5.10 a while ago. Also, the MapDB persistence add-on didn’t work properly. I guess OH3 is for the intrepid bug hunters at the moment who don’t mind working with it and it’s great that folk are happy to do that.
However if you really want to try, it’s quite straightforward… on a Mac anyway… :wink:
I run OH in it’s own folder on the desktop of my MacMini, which also serves as the media and security centre. If you’re a Rpi/Docker/Ubuntu/VirtualBox guy then my tips are of no value to you.
Mac process doesn’t really need any command line/techno/repository/apt-get somersaults:

  • Clean install of OH 3… download, it unpacks itself into a folder & then command line ./start.sh (or drag start.sh into terminal window).
  • localhost:8080 Brings you to a new window which asks you to create an admin user & password (this is new) and then you log on. You now have Basic UI and HABPanel working.
  • Use the UI to install bindings and add-ons etc. Pay attention to zwave binding and give the zwave ‘thing’ the same UID as you had in previous OH so that all your historic items (from OH2) can connect easily without messing around with channels. I use an Aeotec zwave stick. Most of the time auto discovery kicks in, then add all things, naming them as you prefer. The same as OH 2.5 really.
  • You should then bring over copies of your historic items, rules, transformations etc and put into the OH3 folder in the appropriate places.
  • Beware if you’re a fan (like me) of HabPanel. The OH2 Habpanel config file seems to have been dispensed with in OH3 and is now held by OH3 in some json db? You need to ‘export’ the json version of your old Habpanel set up and import that json into the OH3 Habpanel interface.
    I think that’s about it.
10

Or install OH3 usng a different port, using the remoteopenhab binding to connect with your OH2 and migrate at your leisure.

11

Hi Bruce, I don’t understand what advantage that would give me? Isn’t is simple to just copy over a few folders? Won’t there be a conflict between two running versions of OH trying to access the same zwave stick?? Sorry I may be wrong but I’m not as tekkie on this stuff as you guys… :slightly_smiling_face:

12

Thanks Denis! I must do this soon :slight_smile:

13

You can move over the config little by little instead of all at once.

It depends on whether or not your current set of folders use something that is part of a breaking change in OH 3. It could be that simple, it could be a significant amount of work.

No because only one will have the Zwave binding installed at a time. There will be a conflict with ports so you’ll need to configure OH 3 to use a different set or run it on a different machine.

1 Like
14

Thanks for that interesting perspective Rich. I looked up the remoteopenhab binding and it’s very clever indeed! I may try it that way when things mature a bit more with OH3. I’m not clear about the port remapping/changing aspect you mentioned and really I’d prefer to avoid that complication. The initial attempt though of just dragging over folders or parts thereof did actually work fine :slightly_smiling_face: I just had trouble with OH3 messing up/rejecting some (legitimate) zwave configuration parameters which put me off. Also, I found the Parameter Config UI of OH3 to be far less clear and reliable than the old ‘HABMin’ UI from OH2. Habmin is really well designed… just some feedback really. regards,

1 Like
15

I found the Parameter Config UI of OH3 to be far less clear and reliable than the old ‘HABMin’ UI from OH2. Habmin is really well designed… just some feedback

Submit an Issue on GitHub for the ui with examples in order to get this considered as a feature request.

16

Hi Bruce, I’d need to take another close look and make sure I’m being reasonable and balanced…it may have been a coloured impression because parameters were rejected (which was frustrating me :face_with_monocle:) or there was conflict between parameter values entered via the little text boxes and those done via the code tab nearby. I’ll hold off nagging on this till I’m sure and maybe others have had similar reactions. Also, I don’t currently know how to post an issue on Github :shushing_face: … so much to learn…

17

I do not know why they were rejected. That parameter needs to be between 100 & 170.

The entry is here.

Perhaps @chris has more ideas why it is not working as expected in OH3.

18

Yes the entry is allowed to be anywhere between 100 & 170. The text entry boxes kept stubbornly defaulting to -121 (yes a negative number). I entered the 135 I wanted for dimming in the ‘code’ tab entry area. It seemed to stick for a moment or two but then flipped back to -121 Bizarre… :crazy_face: Guess it’ll take a few months to weed out all these gremlins.
BTW, there was similar obstinate behaviour when trying to set the Poll interval of Battery Devices to NO POLL. (battery devices should not be polled).The text box kept picking up the WAKEUP interval value. When I deleted it, it came back but yet the ‘code tab’ area showed ‘null’… this was all very flaky. There should be a simple menu option to choose ‘no poll’.
It might well be that there are other device parameter configs are being affected so hopefully the community might cross-check these values they had coming from OH2 and see if they are held stable in OH3.

1 Like
19

I think this must be an error with the UI - I’m not sure why it would present a default of -121 or why it wouldn’t allow entries in the range of 100 to 170. The parameter definition in the database (and resulting XML) looks fine (see below).

I’d suggest to raise an issue in the webui repository -:

Hopefully @ysc can take a look.

      <parameter name="config_20_1" type="integer" groupName="configuration"
                 min="100" max="170">
        <label>20: Minimum level of the Dimmer</label>
        <description>

<![CDATA[
Enable decreasing the minimum level of the Dimmer<br /> <h1>Overview</h1>

<p>This function will enable decreasing the minimum level of the Dimmer by extending the control impulse. [100 - 170]      </p> <p>By changing the minimem level, the user may completely dim LED bulbs.</p> <p>Not all LED bulbs available on the market have the dimmm</p>
        ]]>

</description>
        <default>110</default>
      </parameter>
1 Like
20

Thanks, Chris

1 Like