Hi at all,
i have a problem with an Aeotec Key Fob Gen5.
if i parse:
ZWaveAPI/Run/devices[15].instances[0]
SceneActivation exists
command classes founded:
32- Basic
89- AssociationGroupInformation
90- DeviceResetLocally
94- ZWavePlusInfo
112- Configuration
114- ManufacturerSpecific
115- PowerLevel
128- Battery
132- Wakeup
133- Association
134- Version
43- SceneActivation
if i parse ZWaveAPI/Data/0
SceneActivation don't exist!
command classes founded:
32- Basic
89- AssociationGroupInformation
90- DeviceResetLocally
94- ZWavePlusInfo
112- Configuration
114- ManufacturerSpecific
115- PowerLevel
128- Battery
132- Wakeup
133- Association
134- Version
It's a problem on api's implementation?
I use latest stable zway version (2.1.1)
ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
Re: ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
Update:
i have upgrade zwave.me at version 2.1.2-rc17 and problem is the same..
Edit: second problem solved with exclude/include process..
i have upgrade zwave.me at version 2.1.2-rc17 and problem is the same..
Edit: second problem solved with exclude/include process..
Re: ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
ZWaveAPI/Data/0 doesn't show not supported (i.e. controlled) command classes, and your SceneActivation could be considered as such because of failed interview.
P.S. I see only one problem described here. Which one was it, and what is the other one?
P.S. I see only one problem described here. Which one was it, and what is the other one?
Re: ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
Hi pofs,
thanks for your explanation!
Because occurs failed interview with Aeotec Key Fob? It's not fully supported?
thanks for your explanation!
Because occurs failed interview with Aeotec Key Fob? It's not fully supported?
Last edited by diapolon on 23 Nov 2015 17:28, edited 1 time in total.
Re: ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
Some detail of second problem.
randomly on some devices ZWaveAPI/Run return strange commandclasses.
Example:
today a "Fibaro Door/Window Sensor FGK-101 - 107"
ZWaveAPI/Run/devices[8].instances[0]
as commanclass 70 (ClimateControlSchedule)
yesterday a "Fibaro Motion Sensor FGMS-001"
ZWaveAPI/Run/devices[16].instances[0]
as commanclass 94 (ZWavePlusInfo)
If i exclude and re-include device it return ok.
Why this?
randomly on some devices ZWaveAPI/Run return strange commandclasses.
Example:
today a "Fibaro Door/Window Sensor FGK-101 - 107"
ZWaveAPI/Run/devices[8].instances[0]
as commanclass 70 (ClimateControlSchedule)
yesterday a "Fibaro Motion Sensor FGMS-001"
ZWaveAPI/Run/devices[16].instances[0]
as commanclass 94 (ZWavePlusInfo)
If i exclude and re-include device it return ok.
Why this?
Re: ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
Up!
I update to latest version, (2.2.1) but inconsistency remains..
http://192.168.1.1:8083/ZWaveAPI/Run/devices[$id].instances[0].commandClasses
If i loop commandClasses of this JSON where $id is node_id i found commandClass that does'nt exist
examples:
http://192.168.1.1:8083/ZWaveAPI/Run/de ... Classes[70] (ClimateControlSchedule) found but device with node 7 is a Fibaro Door/Window Sensor FGK-101 - 107.
http://192.168.1.1:8083/ZWaveAPI/Run/de ... Classes[38] (SwitchMultilevel) found but device with node 14 is a Fibaro Wall Plug FGWPF-101.
Z-wave Expert UI dont'report it, perhaps it analyzes the devices from the configuration files and not from data retrieved?
I update to latest version, (2.2.1) but inconsistency remains..
http://192.168.1.1:8083/ZWaveAPI/Run/devices[$id].instances[0].commandClasses
If i loop commandClasses of this JSON where $id is node_id i found commandClass that does'nt exist
examples:
http://192.168.1.1:8083/ZWaveAPI/Run/de ... Classes[70] (ClimateControlSchedule) found but device with node 7 is a Fibaro Door/Window Sensor FGK-101 - 107.
http://192.168.1.1:8083/ZWaveAPI/Run/de ... Classes[38] (SwitchMultilevel) found but device with node 14 is a Fibaro Wall Plug FGWPF-101.
Z-wave Expert UI dont'report it, perhaps it analyzes the devices from the configuration files and not from data retrieved?
Re: ZWaveAPI/Data vs ZWaveAPI/Run inconsistency
i found how to solve: i have to discard commandclasses when data.supported = false