[config] Add Intermatic PE653 and PE953 pool/spa controller and remote.

[j9brown]

I'm not sure about the VerifyChanged compatibility declarations. The ozw config file only seems to pick up instance 1 and doesn't actually set the verify changed flags.

This device requires polling and verify changes to work correctly. Calling "enablePoll" and "setChangeVerified" at runtime for each value of interest does the trick. What's the best way to encode that here?

[Fishwaldo]

This device requires polling and verify changes to work correctly

It shouldn't. Both are basically doing the same thing - polling continuously polls the device for changes. VerifyChanges will poll the device for changes after we get a update - if two reports are the same it publishes the value.

I don't accept config files that enable polling as thats more of a Policy Decision than a config decision.

VerifiedChanges can be enabled as per https://github.com/OpenZWave/open-zwave/wiki/CommandClass-Compatibility-Flags#all-commandclasses

[Fishwaldo]

This should be auto discovered. Its not needed.

[j9brown]

Per the comment, this is intentional. When auto-discovered, the device presents 6 switch instances however physically there are only 5 of them. By listing them explicitly I am able to suppress the redundant switch instance and label each of them in the same manner as they appear in the product documentation.

FWIW, when I first set up the device, I got fooled by the redundant switch instance and was really confused why the switches weren't controlling the correct loads.

[Fishwaldo]

This should be auto discovered. Its not needed.

[j9brown]

Per prior comment, I'm listing the switching explicitly so as to suppress a redundant instance that should not be enumerated.

[Fishwaldo]

index refers to the ValueID Index - Not instance Index. I don't think you need a entry for each "instance"

[j9brown]

Ok, I will remove the others.

[Fishwaldo]

This should be auto discovered. Its not needed.

[j9brown]

This sensor is auto-discovered but it ends up having the incorrect label and units so I'm listing it explicitly to ensure the correct information is presented to the user.

[Fishwaldo]

This should be auto discovered. Its not needed.

[j9brown]

Unfortunately this is not the case. Auto discovery only detects instance index 1. Also, it ends up with the wrong label and units so I'm listing both thermostats explicitly to ensure the correct information is presented to the user. It took me some time to reverse engineer this.

[Fishwaldo]

No Config Params or Association Groups?

[j9brown]

Unfortunately the config params are very complicated and undocumented. This device is intended to be configured using the associated PE953 remote control. Having watched the traffic between the two, there's a fair bit of manufacturer specific communication going on during that process.

The device doesn't support associations.

[j9brown]

Hope that answers your questions. This device is certainly a little odd. :)

[j9brown]

This sensor is auto-discovered but it ends up having the incorrect label and units so I'm listing it explicitly to ensure the correct information is presented to the user.

[j9brown]

Ok, I will remove the others.

[j9brown]

Unfortunately this is not the case. Auto discovery only detects instance index 1. Also, it ends up with the wrong label and units so I'm listing both thermostats explicitly to ensure the correct information is presented to the user. It took me some time to reverse engineer this.

[j9brown]

Unfortunately the config params are very complicated and undocumented. This device is intended to be configured using the associated PE953 remote control. Having watched the traffic between the two, there's a fair bit of manufacturer specific communication going on during that process.

The device doesn't support associations.

[j9brown]

Hmm, so I just noticed something strange after making these changes and refreshing the node info. I see 10 switches showing up now instead of 5.

I can resolve this by adding "endpoint" to the Instance declarations but it fails make xmltest.

<Instance index="1" endpoint="1" label="Circuit 1" />
<Instance index="2" endpoint="2" label="Circuit 2" />
<Instance index="3" endpoint="3" label="Circuit 3" />
<Instance index="4" endpoint="4" label="Circuit 4" />
<Instance index="5" endpoint="5" label="Circuit 5" />

I must have removed these attributes prior to upload and failed to retest my change (sorry!).

What's the right way of solving this problem while also eliminating the redundant 6th switch endpoint from the enumeration?

[j9brown]

Any thoughts on this?

[Fishwaldo]

You probably need to add https://github.com/OpenZWave/open-zwave/wiki/CommandClass-Compatibility-Flags#multiinstance-commandclass MapRootToEndpoint in the config file - Without all the other CommandClass Info you have right now. Otherwise, please post a log file of the interview after issuing a refreshNodeInfo command.

[j9brown]

Sounds good, I’ll try it but what does MapRootToEndpoint actually do?

…

On Thu, Jul 23, 2020 at 11:59 PM Justin Hammond ***@***.***> wrote: You probably need to add https://github.com/OpenZWave/open-zwave/wiki/CommandClass-Compatibility-Flags#multiinstance-commandclass MapRootToEndpoint in the config file - Without all the other CommandClass Info you have right now. Otherwise, please post a log file of the interview after issuing a refreshNodeInfo command. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAY7BBSOJHQFQXMI2HZQQ3R5EWM5ANCNFSM4OQCTRYA> .