Chris thanks for your helping hands and thoughts. I will send you the requested full log asap via mail :-).
I have AEON multisensors as well and they stopped working after a recent firmware update. It appears the database strongly ties identification to the firmware version. Going from 1.6 to 1.8 broke my devices. If I understand correctly, it looks like yours are version 1.4.
My guess is the database needs to be updated to cover more versions. Note, I did see that 1.8 adds a new configuration parameter so it may be that version 1.8 should have a unique configuration.
Yes - we are working on getting the updated information from Aeon. If you have the engineering spec for 1.8, then please post it…
I haven’t seen an engineering spec, I think the one from 1.7 plus info on the firmware update may be sufficient; relevant excerpt below.
V1.08:
- Disable/Enable LED function has been added (Parameter 80 [1 byte] = 0: enabled 1: disabled).
- Parameter 111-113 no longer restricted by Wakeup Interval, minimum setting can now be set to 240 without restriction.
Note - Faster report time on param 111-113 will deplete battery power faster.
The Somfy controllers also use rollershutters, i’ve found that they also don’t respond to up,down,stop as reported by other users.
It would be great to get this as STOP is the only way to get the blinds to go to an intermediate.
Can you tell me what command class they use? From what I’ve seen they use the multilevel switch which should be mapped to a dimmer type slider to work properly I think?
Yes, SWITCH_MULTILEVEL.
Here is my definition from the 1.x binding.
Rollershutter Bsmt_Blinds “Basement Blinds” { zwave=“28:command=SWITCH_MULTILEVEL” }
In 1.x I was able to the commands UP/DOWN/STOP to the switch. In 2.0 it seems to accept the inputs, but doesn’t take action. Would those commands just be translated to a dimmer value?
In OH1, UP just set the position to 99% (ie max) and DN set it to 0% (ie min). Stop is a separate command.
I’ll take a look at adding this support in OH2…
Sorry to jump into the middle of this thread. I first want to highlight that I am interested in testing out the Security class devices with ZStick, so once I can solve a few issues I’ve had below, I’d like to jump into testing out the newer version of the binding. Security device wise, I have a Kwikset 910 Deadbolt w/ ZWave. From a user standpoint, I’m a long time OH1 user with a Vera Lite integrated into a current OH1 setup. Now testing/moving to Pine64 IoT w/ OH2.
For now I have an Aeon Gen5 Stick in the meantime (Zwave module ships later). I’ve never used it before, so some of this may just be first time usage with OH2. I setup my OH2 instance, got Habmin loaded, and able to get the ZStick registered no issue (mostly). A few quirks and questions I have though:
- LED on the Stick seems to just scroll through red, yellow, blue when plugged into Pine64. I thought I had read it should display one color depending on the quality/signal of the current ZWave network (which with no devices should be blue).
- I was able to successfully pair a couple test devices, they showed up as things, I got them working. How would one go about making them into Items? Is there no direct way in HABmin yet? Do I need to just create items in my items files and reference the ZWave thing Node ID?
- I think I read this behavior somewhere, but can’t seem to find it again. It seems every time I unplug the stick to pair new devices, then re-plug it in, the TTY port changes. Currently it’s ttyACM0, then flips to ACM1. Then upon removal and re-insert, it goes back to 0. Is this normal? Is there a way to set this statically, or to avoid having to always make sure to update the ZWave controller Port Config to the recent address?
- I’ve also found as a side effect of this behavior, that devices are no longer showing Green once I re-insert, even if I update the TTY. Is there a way to fix this, as this could obviously cause much chaos when I try to actually pair my devices and set it up?
- Is there a mechanism for doing a ZWave backup in HABmin or is there a planned feature to do so? I’m not complaining nor do I want to force more work on the great folks who have done the work that has been completed thus far. Just wanted to see if this is one less thing I would need a separate software for. Trying to reduce my smart home footprint to this single Pine64 device and this would help greatly.
Ops please feel free to relocate this post if it makes sense to post somewhere else, I apologize as I don’t often post here.
That’s normal when it’s plugged in to the USB.
Of course - look at the overview here and look at the section Adding Items.
Yes - this is a ‘feature’ of Linux - it’s nothing to do with openHAB. If you look on the wiki, or search the forum, there’s information about creating symbolic links to ports to prevent this.
I would recommend fixing the problem and sort out the symbolic links.
I’ve asked Aeon for information on how to backup their stick and they were seeing if they can provide it. You need to remember that ZWave information is restricted under an NDA so getting this sort of information is not easy!
Please update the database to use the blinds_control channel as per this thread -:
@chris thank you!! That is immensely helpful. I appreciate your answers.
So on the topic of the linux TTY, that explains it. I thought I found something, Symbolic links makes sense, I’ll look around for that detail.
On the items topics, I didn’t see the items created in the normal items location. I’m not sure how OH2 handles creating these items. And when I visited the PaperUI, I didn’t see any actual ZWave items after creating them. Is there a step I’m missing in OH2 to get these ZWave devices into the dashboard.
I have an RF9500 switch which I was able to get Included into OpenHAB2 but it’s showing as ‘Unknown Device’, the resulting nodeX.xml looks ok except for missing ‘nodeInformationFrame’ and ‘nodeNeighbors’ is blank(detected as rf9500 in the logs) but the Attributes in the GUI is showing no information even though it is in the xml. So I’m not sure where to go to continue debugging this.
Please can you provide a debug log of the complete startup of the binding and I’ll take a look.
What does this mean? What are the “normal items location”? If you’re using HABmin, does it shown them in the channels link area as per the link I mentioned above?
@chris sorry, it appears I have a bit of unfamiliarity with OH2 still. Getting my sea legs if you will. So it appears they didn’t appear immediately in the PaperUI under Things. Originally though I had pulled up the PaperUI after adding these successfully and validating functionality. Unfortunately they weren’t there. So I looked for an items files, and didn’t find it either.
As I was going to reply, I tried looking again (just to be sure) and found the Things did exist now in the PaperUI. So the location I was referring to for “normal items location” would have been the items files I’ve been used to. So it seems the items exist, I simply need to map them in the .items files if I would like to do something with sitemaps or other things etc. We haven’t fully made it to the world of OH2 where everything is managed through the GUI. Just getting easier, and in my case coming from MiOS to straight ZWave, HABmin is serving as my MiOS controller interface really, and that’s all.
So I think I’m in good shape now thanks to you, I just need to straighten out the symbolic links and I think I’ll be in shape to try and start testing linking up the Door lock to test the security classes.
Question I leave you with this time, should I be looking at CloudBees for a most recent pull of the binding you’re working on, or should I be pulling from GitHub a completed JAR? I’m sorry I’m playing a bit of catch up, so I’ll likely re-read through the entire thread in the coming week as well as time permits.
In OH2, items are stored in a database if they are created through the UI - there is no items file in this case.
Hmmm - not sure what you mean. Items are items - you don’t need to map them to another item in an items file. Just use them in your sitemap.
If you are using the online runtime of OH2, then it’s simple to upgrade. All you need to do is to go to Extensions in HABmin or PaperUI, uninstall the current binding, then install it again. It will pick up the latest build from Cloudbees…
No problem.
Really - I wouldn’t bother. This thread is a bit too long, and probably out of date a lot of the time.
I would suggest asking questions as you have issues, but I would also suggest to open another thread rather than continuing this one so that others can also benefit…
I had a quick look at the log…
What happens if you wake up the device?
There are two parts of code - the protocol handlers, and the thing handlers (so the ZWave side, and the OH2 side). There are certain events where these two synchronise - firstly during inclusion, and secondly once initialisation completes. Maybe I need to look more at how these can be more closely linked, but that’s how it currently works.
So, in theory, once the initialisation completes, which would be quick given that the XML exists, it should set the information in the thing that is currently missing.
I’ve been trying to find ways to improve this for a while, but it’s not as simple as it seems as all of this runs asynchronously. For example the things might be initialised before or after the controller starts, so it’s not as easy to synchronise when the thing is created, and order is important…