Yes - it’s highly likely. I expect it’s the same problem we came up against yesterday with the network security setting.
I can stop the error by trapping the exception (Assuming it’s the same exception we had yesterday), but if the system won’t allow changing if configuration for things configured through text files, then this is quite a big problem that I have no answer for. I can send the updates to the device still, but as the UI won’t change, you will have no feedback that anything is happening.
I was afraid of that!
Well, at least I then I know. Have to think about how to proceed from here though. I really like the textual route though, so I guess I’ll just hang in there for a while, and see if there’s any decisions in either direction regarding this.
I’m not familiar with how this works under the hood, but I would hope that ultimately, configuration can be stored in the mapdb even for things/items defined in text files…
Yes, this would be great, or some way of exporting mapdb into something editable/readable. Import/export might be good enough.
If I eventually need to go the full mapdb route, looking at it from a historical view, I suppose that I would have to be prepared to build up a new mapdb from scratch every now and then? Or did the mapdb format stay the same for a long time?
I don’t think so. The problem with this is you’ll send a config change through HABmin, and nothing will change in HABmin if it’s using static data. The binding can still update the device config, but unless configuration is treated dynamically, I think it will be a mess.
I meant from a users upgrade perspective - statically export a full mapdb, [then adapting to a new format] followed by importing to a new, fresh mapdb. Then all “runtime” changes are managed through the UI’s. I might be wrong, but currently mapdb from a users (e.g. me ) perspective is just a big black hole. This is of course then outside the zwave binding.
I suppose most people does not have too many things in OH2 yet, but populating my setup properly from scratch I’m guessing at least a full week-end, probably more, even if I save notes about which nodes needs which configuration. And worse; very tedious of course.
I know there’s another discussion around this, somewhere, and I realize the problem marrying textual an GUI settings. Maybe the best compromise is what you are suggesting, with textual items having a overlay in mapdb. At least I guess it might not need any radical changes.
22:05:03.518 [ERROR] [curityCommandClassWithInitialization] - NODE 17: Invalid state! secure inclusion has not completed and we are not in inclusion mode, aborting
22:05:03.523 [DEBUG] [curityCommandClassWithInitialization] - NODE 17: call from NodeAdvancer initialize, from xml, handing back message=null
22:05:03.526 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 17: Since secure inclusion failed, the node must be manually excluded via habmin
ZW100 length error I get
and
Devolo Motion Sensor stays unknown
Thanks!
EDIT: after multiple tries… the Devolo now received the correct name in Habmin! so the log I sent probably shows only a correct initialization. However I had to delete the thing and just restart discovery once more then it was pulled correct.
Same thing I did before quite a couple times…
ADDITIONALLY a NODE1 ! was found now… that should be my controller?! no clue why it shows up in discovery in habmin now???
I would like to delete the Options from the database (parameters 2,3,4)
No possibility to do so
also the Command Classes are not ok (they are populated from the XML?)
e.g. there is DOOR_LOCK in there which is not available for the PIR sensor
delete these non correct classes seems also not available to me?
There are two places where command classes come from - a list in the binding (for the device classes, there are - in theory - a set of mandatory command classes), and the device itself (and there’s two places where the device provides this list). I’ll take a look at the log you sent…
I’ll delete the parameters… I’ll also try and work out the copy function tomorrow… (sorry that’s taken some time).
OK that explains that.
Where does the device class come from in first place?
This one is says SECURE_KEYPAD_DOOR_LOCK for the devolo… Which is wrong … It’s a pir + Temp \ Lumi
Remember that this is all reverse engineered, so occasionally we’ll get things wrong, but we have to make an educated guess from other devices… I’ll have another look at this when I get a chance…
I understood that, but my question is what is wrong with this. If I look at your example above, we have option 0=Off, and it says exactly this in the Overview - same for 255=On. I’m not sure what is wrong with the definitions?
) perspective is just a big black hole. This is of course then outside the zwave binding.
