No - the data is still being decoded and sent as an event -:
2018-06-24 17:52:50.243 [DEBUG] [ass.ZWaveSceneActivationCommandClass] - NODE 16: Scene activation: Scene 24, Time 0
2018-06-24 17:52:50.245 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-06-24 17:52:50.246 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SCENE_ACTIVATION, value = 24
So the thing handler is receiving the message ok but not passing it to the processor.
As suggested, please check the log during initialisation to see what is happening during the channel initialisation. If you’re not sure what to look for, then please provide it for me to take a look at.
Hopefully this is what you mean (I filtered the full log for lines to contain NODE 16 (zwave debug) or node16 (part of the channel name).
This was a full OH restart. If that log excerpt doesn’t show what you’re looking for let me know where to upload the full log, please.
Yes you’re right there is no initialization of a scene_number channel for node 16, I double-checked the whole log, too.
Update: excluded, reincluded device. Now I see a scene_number channel linked, and while I get a SCENE_ACTIVATION message in, the binding now claims it does not know about the command class for that device. Right, it’s missing in the .XML. Tried reinitializing twice already, makes no difference. Puzzled …
So, this log doesn’t show any scene channels being initialised (unless I missed it in the long list ). Possibly it wasn’t in the database previously and now that you’ve excluded/reincluded it’s sorted itself out (you didn’t need to do this by the way - just deleting the thing, and adding it back is all that’s needed to pick up the latest database definition).
Is the command class advertised in the NIF? Can you see this in the XML? A device is required to advertise all command classes in the NIF, and if it doesn’t do this, then we need to update the database to force this manually.
In the past, we used to add unknown command classes if they were heard like this, but if there were corrupted frames, that caused other problems.
I’ll have a look at this, but I don’t think it’s related.
[09:51:20] openhabian@openhabianpi:/var/lib/openhab2/zwave$ ls *_26*
network_c602b032__node_26.xml
[09:51:23] openhabian@openhabianpi:/var/lib/openhab2/zwave$ grep -i scene *_26*
As written, no. Even forcefully deleted XML so it’s recreated for sure from device-advertised data (26 is the new node ID after re-inclusion).
Given it’s a command class that existed in predecessor versions of the product (and the device even trying to make use of it), it should be made available like that I think.
You’re right that still would just be a workaround, so let me know what I can do to find out why the device does not advertise the command class. That re-inclusion I made was a first attempt to find out.
Maybe reset the whole actuator to factory defaults ?
Sorry if I missed this - I don’t see that anywhere? If it’s not in the NIF then we need to force this command class in the database (using the ADD option if I remember correctly).
Sorry - what do you mean by “made available like that”? Do you mean the binding should add the support for adding classes that are not reported in the NIF in the same way as before? If so, I don’t really agree - it was removed to avoid errors and there are other means to add this command class which can be used for non-compliant devices like this?
Sorry if I misunderstand so feel free to correct me.
So that command class is not in the NIF (seems my “as written” statement caused you some confusion - I did’t show any NIFs in my earlier posts, just made the statement that the scene class isn’t in there).
I don’t know how to best get OH/the binding to accept it - I thought the only way is to statically add it to the database, but if you say there’s better means then please choose whatever you feel is most appropriate.
To decide how to do that best is what I meant to ask you for.
Then again, I feel something’s still wrong here. A device to know the class (remember it was included in messages) but to not announce it ? Can’t believe that’s how Fibaro intended to build it. Maybe I’m missing something substantial.
I’m gonna reset that device first to see if that makes a difference.
There are many examples of non-compliant devices. Manufacturers presumably don’t go out with the intention of being non-compliant - they just miss something and it ends up non-compliant.
Just resetted the dimmer, included it, but no luck i.e. no change in behavior.
Still no scene class(es) in XML or NIF, but SCENE_ACTIVATION is sent on S2 button presses.
So it seems Fibaro screwed it up this time, right?
Could you please let me know how to proceed to get the class added to the database ? Firmware version see .XML in my first post.
I’ve updated the database. After the next update in a few days you will need to delete the thing and add it back so that your system picks up the latest definition.
Thanks. Running it. But something’s strange, the whole thing does not work the way I expect it to.
At first, on receiving SCENE_ACTIVATION, binding did still tell me it doesn’t know that class for that device.
Faked its XML (copied another FGD-212’s and changed node ID) to get it to work, played with the parameters and associations and right now, the device is actually sending SWITCH_MULTILEVEL on EP2 (switch_dimmer2) instead of CENTRAL_SCENE or SCENE_ACTIVATION although scene functionality is enabled on S2. Strange, it’s exactly what that guy in that other thread wanted and I told him NOT to set it up like that but to use scenes, now I do myself and don’t know why.
(btw, at least it’s working with the dev binding, including to decode the endpoint, and this is generating an OH event, and I even make use of that for now as long as I don’t get to see scene events).
Second, according to the XML of some other FGD-212 device of different firmware, it cannot do SCENE_ACTIVATION anymore as FGD-211s did but now it knows about CENTRAL_SCENE only. Then again SCENE_ACTIVATION is what I saw being sent. I vaguely believe to recall you once mentioned both of them are mapped to the same, but I don’t know if the current dev binding does, so when I see SCENE_ACTIVATION in binding debug I’m not sure if it really received that or got CENTRAL_SCENE and it was mapped.
Did you statically add SCENE_ACTIVATION or CENTRAL_SCENE classes to the device or both ? If the former, I guess that at least would explain my first observation.
Just to confirm - you deleted the thing, and the original XML, and then added it back again? If so, can you provide the debug log of the initialisation and I’ll see if I can see why it wasn’t added.
Can you provide the XML please. I don’t think I’ve seen the XML and I’d like to confirm what classes are in the NIF. I do however agree that it’s strange if the device is really sending SCENE_ACTIVATION if it’s not supported… I know a lot of devices move to CENTRAL_SCENE which is better designed for use with controllers.
No - they are different command classes and not linked.
Only scene_activation since that’s what you asked for.
I don’t understand this - if we added the SCENE_ACTIVATION command class, then you should not have had the issue that the class was not known right?
Deleted thing but not the XML before resetting/including (then again it was a new nodeID so there was not any XML for that node).
Had some severe problems at that stage after I replaced the binding file, though, to require several OH restarts, now it’s too difficult to find that again.
Now given I need to reset my device once more anyway (no idea else how to make it send scenes again),
will do and send you the output.
Here you are. Unlike I thought it’s the same firmware level as my ‘bad’ one. network_c602b032__node_104.xml (49.0 KB)
Here’s also the current XML of the bad device, last updated during tonight’s network heal, i.e. after I faked XML + included it yesterday: network_c602b032__node_27.xml (48.9 KB)
If the device had been sending CENTRAL_SCENE (the other device to only have that class being a hint) and both classes had been linked to be processed just as SCENE_ACTIVATION was by some common code as I thought I remembered, it could have been just a bad debug output on that part. But since you said they aren’t linked, never mind (I’m still sure we at least discussed that at some point in time, but yes that was well ages ago).
Update:
It now works as expected.
Most recent XML created on re-inclusion contains SCENE_ACTIVATION class but no CENTRAL_SCENE now. Device is sending SCENE_ACTIVATION (plus another SWITCH_MULTILEVEL) while before it was only sending the latter. Had to configure scene activation parameter forth and back once or twice to make that work.
First try was to delete XML and re-include, second to ex- and include, and that one was finally successful although I and needed to restart the binding to make it work. network_c602b032__node_27.xml (46.4 KB) exinclude.xml (391.3 KB) (sorry for faking file type to get it uploaded)
Thanks for your help in adding the class.
PS: no idea where that CENTRAL_SCENE came from in that other device #104… maybe depends on whether there’s a switch attached to S2 at inclusion time (there isn’t any switch attached to #104). Saw that with Qubino actuators earlier but first time with Fibaros.
Thanks. I guess the problem was simply not removing the XML. This would have meant that the binding used the XML data and didn’t try to discover the services again.
I stumbled across this thread while googling for something else. @mstormi, could I ask what you’re using the scene functionality for? I have a few of these dimmers around the house but I’m not doing anything with the S2 switch. Am I missing out on some useful functionality?
I use them to trigger scenes (in a meaning of ‘coordinated control’ of multiple actuators for lights, rollershutters, …) such as an “all-off” button at the front door.
I also use them to remote control some devices (lights, door) that I don’t have switches directly attached to.
That’s interesting, thanks. At the moment I have a single pushbutton (momentary/push-to-make) switch wired up to one of the FGD-212s to allow the double push to set to 100% brightness and the push and hold to dim functions. I might swap the single pushbutton switch for a double switch so I can test the scene activation function. Though this might confuse the rest of my family. Maybe I could find a small sticker of a lightbulb to stick above one of the buttons to indicate which one controls the lights.