Can someone explain why a dimmer needs 4 different ID´s?

[speedy 64]

Hello.

 

I have been using and installing Fibaro for years but this is still a thing i cant really understand.

 

A dimmer with a master number have the ID of 9.

This device then have child devices 10, 11 and 12.

 

I can call 9, 10, or 11 in LUA to control the dimmer. (Why is this possible?)

 

When firmware updates where available in the notifications bar the name of that dimmer is "9.0" and has the ID of 10.

But the actual dimmer that i control in the app has the "real" name of the dimmer "Bel Tak kök" and has the DI of 11.

 

I find it to be very confusing (i know now whats what but not why it is designed this way).

When trying to learn customer block programming and using the system its VERY confusing for them..

 

Senario with a customer:

In the notification menu:

C: Oh, a firmware update is available.

C: But what is it, it has the name 552.0?

M: Well you have to choose the dimmer, press "general" scroll down and then look at the 2nd child device to know the real name of the dimmer..

C: Child device? What is that, its only 1 dimmer. Why can i press all these options?

M: Well, honestly i don't know.

C: So why do i have 3 different dimmers? Do i have to rename all of them and assign rooms to all 3 dimmers?

M: No just the 2nd child device, the rest you cant see in the app and not in the "Unassigned" room, even if it says its in that room.

C: So why can i see these options at all?

 

I think that there is some room for improvement / simplicity in the system.

Maybe a different way to represent the dimmer in the GUI.

Maybe a "Show advanced settings" button or similar if all this is really needed.

 

And also in LUA, i used a VD before that collected all dimmers in a room and then controlled them with a slider.

But now when asking for all the lights using the "isLight" property i always get 3 ID´s from the same dimmer.

 

So if i want to get the "right" ID i can use the "endPointId" property (Number 1 gives the right ID) in this case nr 11.

 

Well, maybe i complicate things, or maybe someone have a great answer.

All answer appreciated!

 

 

ID´s of the dimmer

Please login or register to see this attachment.

ID of actual dimmer

Please login or register to see this attachment.

[Jibran 2]

You are right. Same question from my side too. !!

[speedy 64]

Ok, so i have found that its actually a bug that's been causing me to get all 3 dimmable ID´s when using LUA.

 

Update

-----

So what actually happened was when i added the dimmers all of their child devices where assigned to the room they where added in.

Resulting in getting all the dimmers when getting devices in LUA.

Thats why soft reconfigure didnt do the trick.

Looking in "show hidden" under devices revealed the problem.

-----

 

Soft reconfigure of the dimmer didn't do the trick.

I had to Hard reconfigure the dimmer, then it "reset" having multiple ID´s when calling the device in LUA.

*Thats why it "solved" the problem as the dimmers now where added properly.

 

I added most of my dimmers in V4.1.

 

Does anyone else have this problem that child devices where added in the same room?

 

This is the code i used:

(Change the room number to your specific one if you would like to try)

 

There is also an issue with using this code with old and new Fibaro dimmers. V1 and V2.

Calling com.fibaro.multilevelSwitch with "baseType" doesn't show a V1 dimmer as its called : com.fibaro.binarySwitch

There you have to use "type" to get the same result..

Shouldn't both devices use "com.fibaro.multilevelSwitch" as baseType for consistency?

  

V1 dimmer:

Please login or register to see this image.

/monthly_2017_01/5883d769a446c_FibarodimmerV1.png.f464839f5c9be3214a94ec416c2d9411.png" />

V2 dimmer:

Please login or register to see this attachment.

 

Code to collect all Fibaro dimmers in a room.

Please login or register to see this code.

 

So this is before hard reconfigure (notice ID 49, 50 and 51)

Looks as if i have 5 dimmers in the room.

Please login or register to see this attachment.

 

 

And this is after hard reconfigure:

3 dimmer as it should be. New reconfigured device with ID 184.

Please login or register to see this attachment.

Edited January 21, 2017 by speedy
* Problem found..

[seiq 32]

 

100% agree with all of this.

 

10 hours ago, speedy said:

Shouldn't both devices use "com.fibaro.multilevelSwitch" as baseType for consistency?

Fibaro haven't been known for great consistency in the past. Hopefully it's something they can look forward to rectifying in the future 

[petergebruers 1,268]

34 minutes ago, seiq said:

 

100% agree with all of this.

 

Fibaro haven't been known for great consistency in the past. Hopefully it's something they can look forward to rectifying in the future 

 

Hmmm... Partly that is because things evolve and we still call it a "Fibaro Dimmer" or even "a dimmer". I think you are complaining that a Volkswagen Beetle from 2000 differs form a Volkswagen beetle 2016. If that car *exists* at all, I know nothing about Volkswagen except that they have special firmware 

 

The issue arrises you have probably because none of this explained, except if yo do some research on this forum. And then, still, you have to find the explanation. Hint: I have posted several of them  So I totally understand you say: "this is lack of consistency". 

 

So apart from the fact that Dimmer 1 and Dimmer 2 have 2 switch inputs and 1 output, these are *completely* different devices. I mean *completely* different.

 

The HC2 software matches the device type, and sometimes the firmware version of the device, to offer you the best "GUI" match. So the "template", used to explain the parameter of dimmer 1 and 2 is completely different...

 

I thing the most complex device, that requires a complex GUI, is the RGBW module, because it can operate as a dimmer or input/output... You really cannot fully represent, by the same argument, an RGBW as a dimmer (but it CAN be done as several dimmers...).

 

If this is the kind of stuff that interests you, I can go on for hours.

 

My personal summary of how it works:

 

Device type (product) and firmware determine the properties of one master and several slaves, plus the GUI representation (parameters template).

 

Z-Wave started as a protocol for one module = one function and multi-function devices were added over a period of time. You can see an artefact of this in the "association dialog". There are two columns, "single" and "multi" that probably won't makes sense without an explanation. That's something that is not specific to Fibaro, but to all Z-Wave implementations.

 

You almost exclusively deal with the slave IDS because they represent some part or some function of the device (switch, sensor, output).

 

A device has a physical device ID called "node ID" that is shown, but not used by the end user. Unless we are talking about association, because that's something between two devices and does not youse your controller (for communication). You can compare it to the IP address of an internet device. The need to talk about this number is almost zero. There are ways to confuse your system and make it tell you about the node ID in the status window, but I think that would lead us too far. You can have about 230 physical devices on a single Z-Wave network.

 

Slave and Master IDs are, for all practical purposes, unlimited. Don't worry your ID is 3124... it just means you have had a lot of changes, lots of stuff or an upgrade shifted the IDs

The name and the room can be chosen freely and have no meaning, except grouping and human interaction.

 

Slaves can be in different rooms, because that makes sense. You can have a double relay with one switch in one room and the second switch controlling a light in a different room.

 

[seiq 32]

Ha! I knew there was a possible 'evolution' comment on the way  Yep, I get that. There were other signs of mismanaged development practice's in the past which is why I made the remark. Yes, the issue lies in changing the volkswagen beetle from a 'car' type in 2000 to a 'vehicle' type in 2016 without any backwards compatibility.

 

It's all well and good changing identifying types for backend purposes but not cool when it affect's the end user experience. I'm sure most people would anticipate both dimmer versions to identify as the same type. They both provide the same basic, real world, functionality. IMHO the template/product types should be used in the backend and a generic 'device type' exposed for end user's.  Even if it means Fibaro applying their own categorisation to each templated device. This way they could update the device type if, for example, a dimmer has parameters set to behave like a switch, it would report as a binarySwitch and an RGBW ID programmed to be a 4ch dimmer as a multiLevelSwitch, etc. Just thinking out aloud. I'm sure something can be done to simplify all this by someone much smarter than I...

 

I know why the master/slave devices exist but am of the opinion the interface would be much clearer and cleaner if only the useful device ID's were ever displayed. The 'hidden' device view would become far more useable instead of the dumping ground it is now.

Ideally from the GUI you'd only see:

- 1 channel dimmer = 1 ID.

- 2 channel relay = 2 ID's.

- RGBW programmed for RGBW control = 1 ID (with 3 reserved)

- RGBW programmed as 4 channel I/O = 4 ID's

- Blind module = 1 ID

- etc, etc

[speedy 64]

2 hours ago, petergebruers said:

So apart from the fact that Dimmer 1 and Dimmer 2 have 2 switch inputs and 1 output, these are *completely* different devices. I mean *completely* different.

 

Sure, i get that, but for the end user it should be the same.

It is 1 dimmer output and 2 inputs S1 and S2. 

And in the GUI its not clear whats what. It looks like there is 4 dimmers and not 1 dimmer with 2 inputs.

 

So a more logical representation to me is:

1 Master device (Fibaro dimmer version2) that contains the functions of that master device.

1 dimmer channel

S1 input

S2 input

 

And then pressing device functions shows that child's specific functions / settings, so we don't get the same setting shown over 4 different devices.

 

Something like this:

Please login or register to see this attachment.

 

 

Complete view of a Master device:

Please login or register to see this attachment.

 

 

Pressing "Show hidden devices" results in 100s of this:

Its really not a great user experience och its not clear to me (and i have been installing Fibaro to customers  since V1.xx)

But maybe i havet put any energy into understanding as i can use the system anyhow  and that is also a testament that (to me) that maybe its to much information.

Maybe a more logical solution should be that the child's stay in the room but are hidden and get the name of the master device as default but something like "Kitchen light input S1" and a different icon.

And then an option to "Show input devices"?

 

Please login or register to see this attachment.

 

Edited January 22, 2017 by speedy

[petergebruers 1,268]

@seiq

@speedy

 

Sure... Why not... I like your ideas. They are great and believe it or not, I could say at least a few times: "that's what I would do". You seem to think we disagree that this could be different (and probably easier). But we don't disagree

 

Wasn't the original question: "Can someone explain ..."? That's what I've tried to do in my previous post., Don't you think I tried that as best as I could? If not for you, as experienced members, but also for people browsing topics and wondering the same?

[petergebruers 1,268]

@seiq

@speedy

 

Sure... Why not... I like your ideas. They are great and believe it or not, I could say at least a few times: "that's what I would do". You seem to think we disagree that this could be different (and probably easier). But we don't disagree

 

Wasn't the original question: "Can someone explain ..."? That's what I've tried to do in my previous post., Don't you think I tried that as best as I could? If not for you, as experienced members, but also for people browsing topics and wondering the same?

[petergebruers 1,268]

Ha! Can't remember that I clicked the "submit reply" button two times. But It took at least 30 seconds for it to return. So maybe the forum has some master/slave issues too?  ...

[seiq 32]

@petergebruers Nah mate, no disagreement  Your explanation was spot on! Figured topic was answered haha Just putting forward ideas for discussion on how this confusion could be solved and letting @speedy know he's not the only one suffering these dilemmas 

 

2 hours ago, speedy said:

And then pressing device functions shows that child's specific functions / settings, so we don't get the same setting shown over 4 different devices

Great idea! Keep the global parameters in the master device so it doesn't seem like they are slave specific, correct?

[petergebruers 1,268]

2 minutes ago, seiq said:

@petergebruers Nah mate, no disagreement  Your explanation was spot on! Figured topic was answered haha Just putting forward ideas for discussion on how this confusion could be solved and letting @speedy know he's not the only one suffering these dilemmas 

 

Great idea! Keep the global parameters in the master device so it doesn't seem like they are slave specific, correct?

Thanks. "We're all in it together"  Your remarks will be heard, but they are on the V5 list, not V4.

 

As far as I know, Z-Wave spec (not even plus) does not have the concept of slave specific parameters. So you can't say, for example, that a double relay consists of two slaves, and each of the slaves implements "auto off". That would be clean, but alas we have to do with global parameters. So, for the latest one, FGD-223 that translates to "12. First channel - time parameter for delay/auto ON/OFF modes" and "17. Second channel - time parameter for delay/auto ON/OFF modes (FGS-223 only)". By the same argument in this topic you can ask "why 12 and 17"...

[speedy 64]

22 hours ago, petergebruers said:

Wasn't the original question: "Can someone explain ..."? That's what I've tried to do in my previous post., Don't you think I tried that as best as I could? If not for you, as experienced members, but also for people browsing topics and wondering the same?

 

Yes you did, thank you for that and the time you put in answering that question  and sorry for not acknowledging that.

I got lost in the frustration of GUI representation  

 

Although i now understand that all functions of a device has to have a different ID´s i still don't understand why they are available to us.

Lets take the dimmer for arguments sake.

 

When do we need to see or use a different ID than the actual dimmer ID of the output channel?

 

 

Edited January 23, 2017 by speedy

[speedy 64]

21 hours ago, seiq said:

Great idea! Keep the global parameters in the master device so it doesn't seem like they are slave specific, correct?

 

Thank you, yes thats correct.

Nice to know I'm not alone  

Global parameters in the master device and slave specific in the "child" devices, so we never have more than one place to find and change settings with a logical place to find that setting.

 

20 hours ago, petergebruers said:

So you can't say, for example, that a double relay consists of two slaves, and each of the slaves implements "auto off

So, for the latest one, FGD-223 that translates to "12. First channel - time parameter for delay/auto ON/OFF modes" and "17. Second channel - time parameter for delay/auto ON/OFF modes (FGS-223 only)".

 

Ok, thats all good using a global variable for multiple settings in a device. (and to me the variable can be any numer, letter or sign)

If I'm represented with a slider and a time setting in the GUI, its all good. (maybe if we could change ex the auto off time in LUA numbers a preferred for ease of use)

 

But I think its easy to represent relay specific GUI settings here using the global value on different pages of the GUI.

Its all connected in the background but if you go into relay 2 settings you see the option of "Auto off" for relay 2 but the setting is then saved to the global variable.

We already have this today with different sliders for relay 1 och 2 in the GUI but its displayed on the same page.

Its just a matter of displaying them on different pages of the GUI and saving the setting to the global variable.

 

As english is not my native tongue I'm sorry if i come across as accusing och complaining to you @petergebruers that is not at all what I'm saying or trying to accomplish.

I only want to discuss improvements in the system as I'm passionate about it and think its the best system out there today. (even with some minor annouances)

 

 

 

Edited January 23, 2017 by speedy

[Jibran 2]

Please login or register to see this attachment.

Please login or register to see this attachment.

Please login or register to see this attachment.

I dont understand this. 

As i have tested the dimmer in my basement room. It has selected device id 125 for master device and slave respectively. 

The real id of dimmer on the basement is 127. 

So i dont understand these hidden devices id 125. Why it has selected this id?

Edited January 25, 2017 by Jibran

[petergebruers 1,268]

Hi... Since my last post a few ideas have been presented and I have been thinking nothing beats this small, generic script in explaining what you can do with IDs. The script is only a few lines of code, all the other stuff in the comments is just there to explain the results you get when toy implement this script.

 

To test Dimmer 2, you need a Dimmer 2 with a switch connected to S2.

 

To use it, replace the 7 lines in the header with all the IDs of stuff you want to test. Actually, you can put in any ID you like. The script will print what trigger it got. So, actually, you can just leave my IDs in place and add yours, that'll work too.

 

What can you test? Click the buttons. Or send commands to your device via GUI. Or use a scene to set a device (try all IDs)... See what it prints...

 

Your conclusion should be: Dimmer 2 behaves as if it has a second channel, but there is no physical output. And Dimmer 1 is only one dimmer.

 

Practical use? I don't use it right now, but you *could* make scripts to turn S2 of your dimmer into a remote control, of any other device.

Please login or register to see this code.

 

Edited January 25, 2017 by petergebruers
Typos, syntax coloring

[A.Socha 133]

Hi every device got root and device 0 as min.

 

root - In HC that is information what protocol device use. For dimmer that will be information that is a z-wave device,  - hidden

device 0 - information what type of device it is in dimmer will be a dimmer type

If device support mutichannel then there are more devices

device 1 - copy of device 0  for channel 1 - S1 - hidden

device 2 - information what type of device it is, for channel 2 (S2) in dimmer will be a dimmer type too ) hidden becouse that is a software channel

Please login or register to see this attachment.