Struggling with Channels. Finally working, but questions

Discussion about Z-Uno product. Visit http://z-uno.z-wave.me for more details.
Post Reply
g-knight
Posts: 11
Joined: 09 Oct 2016 19:06

Struggling with Channels. Finally working, but questions

Post by g-knight »

Hi readers
I should say motivated readers, because this post is long. So thank you for reading!

I reused a PIR flood projector electronic and attached Z-Uno on 3 internal points: PIR detection (before inhibit logic by day light), Lamp Relay command and Day Light detector.

On a ZWave standpoint, my needs are:
  • PIR detection should be seen as a Binary Sensor A.
  • Day Light detection should be seen as a Binary Sensor B.
  • Lamp Relay should be seen as a Binary Switch.
  • PIR detection should be able to pilot other ZWave devices trhough Group Associations.
  • Lamp should be actionable by other ZWave devices trhough Group Associations.
After some struggling, reading the documentation and a lot of ZWave inclusions / exclusions I managed to make all the above working. I'm using Domoticz and its working well.

However, I have some questions on the Z-Uno Channel management.

After some unsuccessful attempts, I started again from scratch progressively to better understand (full code is at the end).

Bellow are all the steps. Unfortunately, I could not put each image just below the text at the right place, because this forum allows only 3 attachments. So I grouped all pictures into a single file and reference them by number.
Figures.jpg
Figures.jpg (253.32 KiB) Viewed 10153 times
Step one: just added one Binary Switch for the lamp

Code: Select all

ZUNO_SETUP_CHANNELS(ZUNO_SWITCH_BINARY(getterLamp, setterLamp));
After inclusion, I have 2 channels that are detected into Domoticz (with ID 0x1D)

Fig 1

And getterLamp() is called 3 times (see full code at the end)..
If I click on the device 1D01, both lamps on Domoticz are on:

Fig 2

And if I use the device 1D02, only lamp 2 on Domoticz is on

Fig 3

So far so good, just have to know that lamp is device 2.

Questions:
  • Why two devices?
  • Why this copy of Switch one => Switch two?
  • Is that related to the explanations on the "mapp to root device" that we can find from place to place in this forum?
Next step: adding the PIR sensor.

Channel setup becomes:

Code: Select all

ZUNO_SETUP_CHANNELS(
  ZUNO_SWITCH_BINARY(getterLamp, setterLamp),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir)
);
After inclusion, I have now 6 channels into Domoticz (ID 0x1E):

Fig 4

And getterPir () is called 2 times.
On PIR detection (it triggers a zunoSendReport(2)), lamp corresponding to Switch 2 on Domoticz is on.

Fig 5

Not good! Switch 2 is the Relay!
With the experience I got from former trials, I decided to add another sensor. Channel setup becomes:

Code: Select all

ZUNO_SETUP_CHANNELS(
  ZUNO_SWITCH_BINARY(getterLamp, setterLamp),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir2)
);

PIR detection now triggers a zunoSendReport(3).
Going quicker to the conclusion for this step, I got this in Domoticz:

Fig 6

And now PIR is not interfering with Relay, I have Relay working as device 02 and PIR working as device 03:

Fig 7

Questions:
  • Is this need to add a "dummy" sensor related to the same "mapp to root device" consideration?
  • What are those "Sensor", "Alarm Type", "Alarm Level", "Burglar" & "Sensor"? Is it a bad interaction between Z-Uno and DomoticZ?
Last step, adding the Day Light detection.

Channel setup becomes:

Code: Select all

ZUNO_SETUP_CHANNELS(
  ZUNO_SWITCH_BINARY(getterLamp, setterLamp),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir2),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterLum)
);
A new device shows up as Sensor id 4 (renamed into Sensor Z04) that correspond to Light Detection, and I have a total of 8 devices now.

Fig 8

And it works well with the dashboard:

Fig 9

Groups management

Now, playing with group was really simpler.

Just had to add

Code: Select all

ZUNO_SETUP_ASSOCIATIONS(ZUNO_ASSOCIATION_GROUP_SET_VALUE);
and zunoSendToGroupSetValueCommand(CTRL_GROUP_1, ....
for being able to drive another device from PIR detection.

And Driving the Relay was given "out of the box" with standard Group Associations.

Just a question:

The Z-Uno Is showing "1.1" (figure 10) as its ID in the Domoticz Group Association management screen. This is the first time I see such a "doted" notation. Looks weird. Can somebody provide an explanation?

The conclusion

Even if a little bit tricky to understand well, this Z-Uno is really a good device. I think there is a tremendous job done to make it "Arduino like" (including hiding ZWave stack and the 8051 tool chain integration). Congrats for designers!

Thanks again for your reading and (I hope) answers.

Gerard

The whole code is here:

Code: Select all

#define DEBUG
#define REL_PIN     10
#define LED_PIN     13
#define PIR_PIN     6
#define LUM_PIN     22

// Globals holding current states
byte lampState;
byte lastPIRState;
byte pirState;
byte lastLumState;
byte lumState;

ZUNO_SETUP_CHANNELS(
  ZUNO_SWITCH_BINARY(getterLamp, setterLamp),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterPir2),
  ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getterLum)
);

// Groups declaration
// !! Real association groups number are shifted by one. Means CTRL_GROUP_1 is in reality number 2. This is because number 1 is Life Line group.
ZUNO_SETUP_ASSOCIATIONS(ZUNO_ASSOCIATION_GROUP_SET_VALUE);

void setup() {
  // Set I/O Directions
  pinMode(LED_PIN, OUTPUT);
  pinMode(REL_PIN, OUTPUT);
  pinMode(PIR_PIN, INPUT);
  pinMode(LUM_PIN, INPUT_PULLUP);
  
  // Global variables initialisation
  lampState = 0;
  pirState = lastPIRState = LOW;  // Not reading actual value from pin for this test
  lumState = lastLumState = digitalRead(LUM_PIN);
  Serial.begin();
}

void loop() {
  // Get motion state from PIR
  // pirState = digitalRead(PIR_PIN); ==> nor working, using temporarilly analogRead
  int val = analogRead(A3);
  if (val > 500)
    pirState = HIGH;
  else
    pirState = LOW;

  if (pirState != lastPIRState) { // Transition detected on PIR
    lastPIRState = pirState; // save new state
    if (pirState == HIGH) { // Motion detected
      digitalWrite(LED_PIN, HIGH);  // LED on
      #ifdef DEBUG
        Serial.println("Motion detected");
      #endif
    } else {
      digitalWrite(LED_PIN, LOW);   // LED off
      #ifdef DEBUG
        Serial.println("No more motion");
      #endif
    }
    zunoSendReport(3); // Report motion over ZWave
    zunoSendToGroupSetValueCommand(CTRL_GROUP_1, (lastPIRState == 0) ? 0 : 0xff); // Trigger Group cmd in case of an association made
  }

  lumState = digitalRead(LUM_PIN);

  if (lumState != lastLumState) { // Change detected on Lum
    lastLumState = lumState; // save new state
    if (lumState == HIGH) {
      #ifdef DEBUG
        Serial.println("LUM is HIGH");
      #endif
    } else {
      #ifdef DEBUG
        Serial.println("LUM is LOW");
      #endif
    }
    zunoSendReport(4); // Report Lum over ZWave
  }
}

// Callback for Lamp Set Value. The Relay on REL pin drives the lamp
void setterLamp(byte value) {
  #ifdef DEBUG
    Serial.print("setterLamp called with "); Serial.println(value, DEC);
  #endif
  if (value > 0) {
    digitalWrite (REL_PIN, HIGH);
  } else {
    digitalWrite(REL_PIN, LOW);
  }
  // we'll save our value for the situation, when the controller will ask us about it
  lampState = value;
}

// Callback for Lamp Get Value
byte getterLamp() {
  #ifdef DEBUG
    Serial.print("getterLamp called, returned "); Serial.println(lampState, DEC);
  #endif
  return lampState;
}

// Callback for PIR Get Value
byte getterPir() {
  #ifdef DEBUG
    Serial.print("getterPir called, returned ");Serial.println((lastPIRState == 0) ? 0 : 0xff, HEX);
  #endif
  return ((lastPIRState == 0) ? 0 : 0xff);
}

// Callback for PIR 2 Get Value
byte getterPir2() {
  #ifdef DEBUG
    Serial.print("getterPir2 called, returned ");Serial.println((lastPIRState == 0) ? 0 : 0xff, HEX);
  #endif
  return ((lastPIRState == 0) ? 0 : 0xff);
}

// Callback for Lum Get Value
byte getterLum() {
  #ifdef DEBUG
    Serial.print("getterLum called, returned ");Serial.println((lumState == 0) ? 0 : 0xff, HEX);
  #endif
  return ((lumState == 0) ? 0 : 0xff);
}

User avatar
PoltoS
Posts: 7565
Joined: 26 Jan 2011 19:36

Re: Struggling with Channels. Finally working, but questions

Post by PoltoS »

Channels and mappings are explained here: http://z-uno.z-wave.me/Reference/Z-Wave/#Channels
The "asymmetric" update is certainly due to MCA versus Associations set up in LifeLine. How have you configured your associations in group #1 (LifeLine)?

Once you add a sensor, looks Domoticz starts mixing channels. Not sure how Domoticz is made internally.

> "Sensor", "Alarm Type", "Alarm Level", "Burglar" & "Sensor"
In this case you should see:
:0 Switch Binary
:0 Sensor Binary
:0 Alarm
:1 Switch Binary
:2 Sensor Binary
:2 Alarm

The Sensor Binary + Alarm are for backward compatibility with old controllers.

Certainly seeing Switch Binary + Sensor Binary + Alarm on root device :0 makes Domoticz crazy. Though, this is allowed and legal in Z-Wave.

The 1.1 is the MCA (MultiChannelAssociation) with Domoticz channel 1. This now responds to my question above about your associations. If you change it to 1:0, it will work properly (symmetrically) on yourr two switches in the very first step.

Thanks for using Z-Uno!
g-knight
Posts: 11
Joined: 09 Oct 2016 19:06

Re: Struggling with Channels. Finally working, but questions

Post by g-knight »

Hi PoltoS

Thank you for your answer.

I red several times the page you mention for channel documentation, but unfortunately, it doesn't help me to understand the problems I noticed.

However, even if I don't understand 100 % why there are two channels for the switch with the copy, as it works with the ID 02, it's OK.

Considering the Association Group management, I do have the "1.1" before doing anything. Bellow is what I get just after inclusion with an "empty" sketch that only blinks the LED. So, there is no MultiChannelAssociation.
InitialGroups.png
InitialGroups.png (9.12 KiB) Viewed 10141 times
And the code is:

Code: Select all

void setup() {
  pinMode(13, OUTPUT);
  Serial.begin();
}

void loop() {
  digitalWrite(13, HIGH);
  Serial.println("ON");
  delay(1000);
  digitalWrite(13, LOW);
  Serial.println("OFF");
  delay(1000);
}
Gerard
User avatar
PoltoS
Posts: 7565
Joined: 26 Jan 2011 19:36

Re: Struggling with Channels. Finally working, but questions

Post by PoltoS »

MultiChannelAssociation is always enabled. This means to send reports to channels. Your controller might not support association to 1.0, since this is a new feature in Z-Wave.
g-knight
Posts: 11
Joined: 09 Oct 2016 19:06

Re: Struggling with Channels. Finally working, but questions

Post by g-knight »

Thank you for your answer.

I'm not sure it's not working, it was just I was astonished by this "1.1" I never saw before. I'm not so much skilled considering ZWave...
I'll have a look on this topic later on.
Post Reply