Multi-switch in-wall relay switch multi-channel/multi-endpoint values get misattributed

Greetings, I have a problem with a Z-Wave device. Running OpenHAB 2.0 stable release.

  • The device in question is an in-wall relais module device.
  • Specifically the Philio PAN04.
  • I created a gist over there which contains the The OpenHAB node XML file from the local OH2 installation, and all detailed product links for direct access.
  • It responds to both basic and multi-channel commands.
  • It has two separate ralais/binary switches inside, which can be controlled separately.
  • It has multiple endpoints: 1 for switch 1, 2 for switch 2 and endpoint 3 for 1+2.
  • The OpenHAB device descriptor file from the zwave binding .jar file (philio_pan04) includes the basic commands and the 3 endpoints = 4 sets of commands.
  • For each set of commands, there is a switch and multiple electrical values (watts, voltage, kwh, ampere).

Problem is:

  • The OH2 items for the separate relays/switches work, but the reported values (current, kwh, ampere, voltage etc.) do not.


  • The OH2 events log file shows bundled updates to the same item:
2017-02-19 18:35:14.800 [ItemStateChangedEvent     ] - zwave_node13_meter_watts changed from 0 to 3.9
2017-02-19 18:35:15.002 [ItemStateChangedEvent     ] - zwave_node13_meter_watts changed from 3.9 to 4.6
2017-02-19 18:35:15.400 [ItemStateChangedEvent     ] - zwave_node13_meter_watts changed from 4.6 to 3.9

After that, on each report from the device, it shows:

2017-02-19 18:36:29.715 [ItemStateChangedEvent     ] - zwave_node13_meter_watts changed from 3.7 to 4.9
2017-02-19 18:36:29.850 [ItemStateChangedEvent     ] - zwave_node13_meter_watts changed from 4.9 to 3.8

To me it seems, that the values from endpoints 2 and 3 = the separate relays/electrical channels are misattributed to the first (basic) value.

Expected would be:

2017-02-19 18:36:29.715 [ItemStateChangedEvent     ] - zwave_node13_meter_watts1 changed from 0 to 4.9
2017-02-19 18:36:29.850 [ItemStateChangedEvent     ] - zwave_node13_meter_watts2 changed from 0 to 3.8

… but unfortunately, the meter_watts1 and meter_watts2 values never get updated. It all gets “squished” / misattributed to the meter_watts item.

The only time these meter_watts1 = first electrical channel and meter_watts2 = 2nd electrical channel are updated, is when I go into HABmin, select the device and re-initialize it … then, in the DYNAMIC_VALUES phase, it updates the meter1 and meter2 values (and also the other *1 and *2 items, like current1 or kwh2 etc.)

Where does the misattribution of the values come from and how can I fix it so that the *1 and *2 items are updated?

Looking forward to your response.

1 Like

+1 @chris . I have similar problem, when no update on ‘internal’ endpoints is being received. I had to set polling, because only master switch received updates.

This is associated to the way that associations are enabled in these devices. It requires the use of the multi-channel association, and it needs to be configured in a specific way. This is only done on recent snapshots.

If this isn’t working, then please provide a log showing the setting of the association and I’ll have a look.

Where these snapshots can be downloaded / when the corrected version comes into main repository, then?

Snapshots are available if you are using the snapshot runtime. To run snapshot versions with the released runtime will be more problematic but there are discussions on the forum about this.

@chris, I’m also having problem with PAN04 and reporting state of relays - I’m not able to make reporting a state working at all. I’m running OH 2.1.0-1 installed from deb package. As your post is from March, can you please say whether this ‘feature’ related to multichannel configuration is already present in this release of OH or not?

I (as well as @ERnsTL) work for a young Smart Home company in Berlin. We use openHAB/ESH and Z-Wave devices to realise energy savings for real estate owners in apartements.
In general, everything works well, but this bug is a big issue for us, which we need to get rid off, so we are ready to spend time to debug and provide all necessary information, as well as money to anybody who fixes it.

One of the devices we typically work with is the Philio PAN04 which can switch two 230V relays and measure several properties like A/V/W etc. on each channel separately as well as combined. Our main focus is on the instantaneous power consumption (watts), so I’ll concentrate on that below as an example. However, the description applies to all it’s channels as well as other multi endpoint devices.

The problem is hard to catch and changes characteristics between OH/Z-wave binding versions:

  • As reported above, in OH 2.0/2.1 it seems that the value received as COMMAND_CLASS_METER gets misattributed or even a value from the one relay may overwrite the one of the other.
  • In latest master branches of ESH/OH/ZW, always only endpoint 0 (the one to measure both relays combined) gets updated
  • In latest Z-wave development branch, nothing gets updated ever. All values always stay “-NaN” or 0.0

Using the “polling” mechanism, all Channels get updated correctly.

Two logs (master/development branch) can be found here: , showing startup in Eclipse IDE, adding node as thing and switching the relay on and off again. Logback has been customized to get rid of most irrelevant lines and include TRACE level. Also, I attach the xml descriptions created in userdata/zwave/ for both cases:
node2.xml (20.2 KB)
network_d8608903__node_2.xml (21.2 KB)

It seems, that there are others experiencing the same problem:

@chris what can we do or provide, how can we help to track down and fix the problem? Or can you maybe give some hints on what would be the best starting point to look at for us to create a PR?


This is a complex area as there are many different versions of command classes employed here, and within versions, everyone seems to interpret things differently.

If someone wants to provide me a device for testing then it would also help - I already spend £££ each year on devices for testing so I’m a little hesitant to spend more right now.

Thanks for your quick reply! That shouldn’t be a problem,we should be able to provide you with the needed devices.
Do you have an amazon wish list where you could put a a and a ? Or what would be your preferred way?


Off the shelf (ie without any changes) this device doesn’t report multi_instance_association, and therefore the binding uses the standard association command class to set the associations. The Zwave standard states that this means that the device will not encapsulate the devices with the multi_instance command class, so only the root association will work.

This is what I see - if I change the state of button 1, then it updates fine in the root endpoint. But the two MC status’ don’t update.

This is a reasonably new concept for ZWave (only added in the past few years) and there are many implementations - the command classes themselves have changed a few times, and how manufacturers interpret them has also been a bit variable making this a real pain in the behind to resolve!

I tried to force add this command class to the device, but it definitely doesn’t support this feature.

From a search around the web, it seems that this device can’t/doesn’t report its data using multichannel encapsulation, so there’s no way to tell the different endpoints apart from the associations unfortunately :frowning: .

The only option to resolve this that I can currently see is to poll the device. Potentially setting up a rule that uses the switch 0 status change to poll the other switches. This isn’t 100% fool proof, since it you turn on switch 1, then turn on switch 2, there is no update sent.

I will try and contact the manufacturer to confirm this, but as they are in China, I’m not overly hopeful that I’ll have a response.

Oh, sorry that I didn’t see your reply earlier! :frowning:

Thank you for your effort you put into this issue! It is quite sad, that those Philio PAN04 devices do not support the necessary commands correctly.

But I am a little bit confused, as we use no associations in our setups and from looking at the logs, it seems that the messages are received correctly but misattributed afterwards, overwriting each other. Our specific use case is to monitor the meter_watts channels of the two loads and record all changes to the mysql persistence provided by OH on every change.
Do I understand you correctly, that the binding correctly receives the meter reports, but because of the wrong implementation by the manufacturer, cannot know for which channel/item they are targeted and so applies the new value to both?

Is this the same for the Aeotec HEM, for which we experience the same problems?


I’m not sure what you refer to? The issue is that there is no multi-channel encapsulation, so what happens is the device sends switch 1 status, then maybe later it sends switch 2 status - both of these will be decoded exactly the same as there is no MC encapsulation to tell the binding what switch it came from.

I think this is the same - it receives the root endpoint ok, but as there is no MC encapsulation, if other endpoints are also sent, then there’s no way to know the difference.

I should add that I emailed the manufacturer, but received no response…

I did not get the chance to check the HEM - I will try and do so over the weekend.


Allright, thank you very much, I think I completely understand the problem now and we will have to use a different vendor.


Hi again @chris,
did you have a chance to check the Aeotec HEM about the problem?


Hi, how exactly can I “poll” the switch state from the rule?

You can poll using the REFRESH command.