6, almost 7 hours has passed, after I deleted two qubino dimmers xmls. One of them, node 79 has still not come out of initialisation - it seams to be stuck at “ASSOCIATIONS”. This node has second button as input to an OH rule controlling the other Qubino dimmer, not that I think this is relevant.
Now, it always takes a lot of time for my zwave network to come back after a restart and be responsive, but this seams a bit too long for the one node.
There’s still two battery nodes that are also waiting, which is normal - but could they hinder node 79 to progress in its init sequence?
If I control it from webui, the node works - i can dim it up and down, and its second button does control the other light over an OH rule.
Sounds too long… If you have a log, feel free to send it over (create a ticket on my website). If it’s stuck in a specific place, then if you can get a log showing a few cycles of repetition that would be good.
now i’m using openhabian with OH 2.1 stable, does switching to OH 2.2 unstable using openhabian-config result in using fixed z-wave development version ? or I have to install the jar manually ?
PS. I understand that it is not possible to use fixed z-wave binding with OH 2.1 ?
There are three version of the zwave binding: stable, snapshot, development.
If you are on a stable openHAB2 runtime version, you cannot update to the snapshot or development version of the zwave binding (and it does not make sense because changes in the binding do not match the openHAB runtime)
If you are on a snapshot openHAB runtime, you can update the snapshot zwave binding with simply uninstalling it through PaperUI, wait a minute, install it again.
If you are on a snapshot openHAB runtime, you can update to the zwave development version of the binding by uninstalling the snapshot zwave binding, download the development version of the zwave binding and drop it into the addons folder. In this case you may also need to install the serial transport dependency manually through the console.
I know it gets complicated sometimes, but all this is necessary to not break the system for users using openHAB stable and at the same time implement new features/fixes for users on unstable openHAB2 runtime versions so they can test it (for the benefit of the next stable release).
After my initial test of develoment and qubino response
i deleted the things, removed zwave binding(paper-ui),deleted zwave xml’s, stopped openhab2 service, copied new zwave jar, started service, logged on console and feature:install openhab-transport-serial
my 3 units of flush2relay works right away
my only flushdimmer does not work
a whole bunch of flush1relay does not work
Not tested yet flush1d and flush shutter DC
Then i had some new units newer used before.
Started with a flush1relay and it is working!
Next i tried a flushdimmer and that also worked!
What am i missing or what can i try?
Do you want any logs of this and what should they contain?
Thanks for looking into this, Chris! I have one Flush 2 relays unit that I’ve never got switch status updates from in OpenHAB and I hoped your fix would solve it. Unfortunately, this is not the case, yet.
According to the instructions in this thread, I have removed the unstable variant of the Z-Wave binding and dropped your jar file into addons. This works fine, and after removing devices in Paper UI and re-adding them from the inbox I can control Z-Wave devices from my main UI. Other devices, such as a NodOn wall plug, sends a status update when I switch it directly on the plug and the UI is updated within a seconds. However, the Flush 2 relays status is not updated at all.
It should be noted that even though I set the log level for the Z-Wave binding to DEBUG, there are no log messages at all when I switch one channel on the Qubino device using a wall switch.
I recall reading that Qubino devices may behave differently depending on how the controller was acting when it was included in the Z-Wave network. So, despite your instructions earlier, is it possible that I actually have to exclude and re-include the Qubino device? I have not managed to get exclusion working from Habmin, so before trying that, it would be good to know if there is a chance that it solves the problem.
There must be something wrong with your setup or the way it’s configured since logging should work. You need to find out what’s up with this first.
Sorry for being unclear. Logging works fine when e.g. changing a switch in the UI. It’s when I push the switch on the wall (and the lamp lights up) that nothing is seen in the log. I suspect this is because the Qubino device actually doesn’t send any messages.
It’s unlikely unless you have changed the configuration (ie the endpoints - added thermometers or something).
No, I haven’t changed anything in the configuration.
So, in that case I suggest to reinitialise the device and send me the log. I want to see what happens during the initialisation. Best is to create a ticket on my website (cd-jackson.com) and you can attach large files there (you’ll need to register to see this option to open a ticket).
Yes the only old device that works are flush2 units, flush1 and flushdimmer did not
when i tried to include a new device flush1 it works and the new flushdimmer works
@chris, did You have had any time to look into the ticket I created (and does it contain the relevant information)? Seeing as @Daniel_Linder sees the same thing, at least I’m not alone.
My node 79 is still stuck at ‘ASSOCIATIONS’ so something is the matter here.
Sorry, I forgot to reply on this. Your log didn’t really have anything much in it for this node.
I see a bunch of TIMEOUT_WAITING_FOR_CONTROLLER but I’m not really sure why since there doesn’t seem to be any messages being sent to the device at all.
But no data is being sent, so of course there is no ack . Maybe the log doesn’t have everything, but as I showed above, in the log you sent me there is no data at all being sent to node 79. I don’t know why this is, and there are strangely long gaps of no data in the log - maybe there’s an exception logged somewhere else, or I don’t know, but from what I see in the log, I have no ideas of what is happening - sorry.
Ok - did you remove any receive/transmit data lines? For me the mystery is why there is no data being sent to, or received from this device in the logs you provided…
.
. Maybe the log doesn’t have everything, but as I showed above, in the log you sent me there is no data at all being sent to node 79. I don’t know why this is, and there are strangely long gaps of no data in the log - maybe there’s an exception logged somewhere else, or I don’t know, but from what I see in the log, I have no ideas of what is happening - sorry.