Zwave Issues with OH2 (Switch Updates)

[norbert_jordan (N. Jordan)]

Chris, did you find out anything. Was the log file long enough for this purpose?

[chris (Chris Jackson)]

Sorry - I missed your response (since you didn’t reply to my message I didn’t get a notification). I’ll take a look tonight.

[chris (Chris Jackson)]

I can’t find any reference to the items that you mentioned above, but I see the following errors in the log that I suspect are not a sign that things are working well and are likely related to this problem.

2017-09-03 14:16:07.260 [WARN ] [assic.internal.render.SwitchRenderer] - Cannot determine item type of 'FGS11_Switch'
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'FGS11_Switch' could not be found in the item registry
2017-09-03 14:16:07.269 [WARN ] [assic.internal.render.SwitchRenderer] - Cannot determine item type of 'FGS12_Switch'
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'FGS12_Switch' could not be found in the item registry

[norbert_jordan (N. Jordan)]

Thanks Chris, no - the FSG12_Switch is one of the few onces still not transferred to OH2 binding, so a link is missing.
These are “bad” switches that do not update their state on regular “polled” basis…I set it to 300 + Associaton Group 01
Node 49 - PVng5Mono_Switch
Node 50 - PVng5Poly_Switch
Node 08 - Solar_Switch

Here is a way longer log, I hope you can extract something from there…Thanks Norbert

https://1drv.ms/u/s!AqVcwrl1pLMGtAvqCuDFSYhXYJs0

[chris (Chris Jackson)]

I’ve not looked through all 100MB of the logs, but the 2 logs I’ve looked through I see no switch status updates. Polling is disabled for these switches - normally this is done as polling causes a problem with the device. If you have associations enabled, then the device should update when it changes state.

[norbert_jordan (N. Jordan)]

OK. But if I understand this right - polling is pro-active forced by the controller. has nothing to do with the clients. right?

Could there be any wrong settings in serial controller? see below my setting

[chris (Chris Jackson)]

@norbert_jordan

if I understand this right - polling is pro-active forced by the controller. has nothing to do with the clients. right?

Correct. As I said, polling is disabled for this device so you should use associations.

[norbert_jordan (N. Jordan)]

not sure what you mean by “this device”. The USB-Stick has polling disabled so it does not poll the switches?
And what is ment by associations…i only can set in HABMIN the association group, so where the SWITCH will send pro-active messages if he wants to…

Is the setting correct of the usb-stick, can you please check, as i’m not sure if all is set as it should.

Maybe I did not say this before, in OH1 polling worked normal, so the SWITCHES did update forced by the STICK.

[chris (Chris Jackson)]

@norbert_jordan

not sure what you mean by “this device”.

This device type does not support polling - this is configured in the database to disable polling on all devices of this type.

@norbert_jordan

And what is ment by associations

Associations are used to send reports to the controller when the device state changes. This is the fastest and most efficient way to update the system.

@norbert_jordan

Is the setting correct of the usb-stick,

There aren’t really any settings in the controller - what you had looks fine.

[norbert_jordan (N. Jordan)]

Sorry - maybe i’m stupid.

You mean that the following SWITCHES do not react to polling?

• PAN11 Smart Energy Plug-In Switch
• MT02646 HomeControl Metering Plug
• 123665 Wall Plug Meter Switch

Because, how can OH1 then have supported (by whatever means if it was not polling) that these SWITCHES got updated after few minutes from restart of Openhab? Maybe you have any clue…

[chris (Chris Jackson)]

@norbert_jordan

You mean that the following SWITCHES do not react to polling?

I’ve not checked the database since I don’t know what nodes are related to what switches (you haven’t said previously what the devices are I think?). All I can say is that in the log it says that the device doesn’t support GET requests. I guess this would have been the same as OH1, but I haven’t checked as I didn’t know what the devices were.

I don’t know when this was added to the switches, or why, but it’s normally to resolve a problem with the device.

[5iver (Scott Rushworth)]

Have you tried manually waking up the devices?

Also, when you migrated from OH1, did you use the items file in OH2? If so, could you post it along with the section of your sitemap that has them? I saw a couple odd things in your logs that made me suspicious of the item channel configuration. It would also be helpful to know exactly which nodes are the troubled ones.

[chris (Chris Jackson)]

@5iver

Have you tried manually waking up the devices?

From what I can tell, then are mains switches. They are regularly reporting meter data…

The binding is not sending the requests to the device - it’s not a case of them sleeping (mains switches won’t sleep anyway). The is because the database has the NOGET option set (at least for the PAN11 and the MT02646 - I’m not sure what nodes they are).

[5iver (Scott Rushworth)]

Gotcha… I saw he referenced some plug-ins, but wasn’t sure if there were possibly some battery devices in the mix.

[norbert_jordan (N. Jordan)]

thanks all for your effort…really frustrating.

PAN11 for example is Solar_Switch…Node8
MT02646…is PVng5Poly and PVng5Mono…Node 49 & 50.
Especially these never update…at all.

So Chris, you say that for sure these device brands have no chance at all to react to polling…
Again, its strange to me how it ever could have worked with OH1. But i get what you say.

All are plug-devices, so all time online, never sleeping.

[norbert_jordan (N. Jordan)]

what is “polling” called in PaperUI Things properties?

zwave_listening true (???)

[chris (Chris Jackson)]

@norbert_jordan

So Chris, you say that for sure these device brands have no chance at all to react to polling…

Currently, this is disabled in the database. As I said, I don’t know why this is - maybe it’s incorrectly set, but that’s the way it is. If you think it’s wrong, then please feel free to change it and we an see if it works, but it’s likely it was set this way for a reason.

OH1 database is not configured like this.

@norbert_jordan

All are plug-devices, so all time online, never sleeping.

Yes.

@norbert_jordan

what is “polling” called in PaperUI Things properties?

It’s just called “polling time” - there’s nothing else.

@norbert_jordan

zwave_listening

No - this is a low level zwave device attribute. It basically indicates if the device is a mains device or a battery device.

[norbert_jordan (N. Jordan)]

sorry, Chris - that this is a slow progressing item…but things start to get clear now.

Recap:
The named plug-brands are definitely “disabled” for polling. so what we see in the logs has to be that way as the 3 plugs are per DB not able to react…unclear if they could, but not tried yet.
As you are the incredible chief of zwave binding - was the DB as well disabling polling in OH1 for the named plugs?

Can you advice me for example how to enable polling for the PAN11-devices…which files to touch.

[chris (Chris Jackson)]

@norbert_jordan

was the DB as well disabling polling in OH1 for the named plugs?

No - that’s what I said above - OH1 database is not configured like this.

What I suggest is the following. Stop the binding (or stop OH), then edit the XML file for this node. In the XML you should find something called <isGetSupported>false - either remove this line or change it to true. Then restart and it should now work.

[norbert_jordan (N. Jordan)]

something called false? there are more than 6 false in the xmls…

do you mean this part?

<entry>
  <commandClass>SWITCH_BINARY</commandClass>
  <binarySwitchCommandClass>
    <version>1</version>
    <instances>1</instances>
    <versionSupported>1</versionSupported>
    <isGetSupported>false</isGetSupported>
  </binarySwitchCommandClass>
</entry>
<entry>