Yes, if you’ve had them working previously, then they will probably wake up on their own. Probably this should happen in a few hours.
Thank you and thanks for all of your contributions!
1 Like
So if we remove the meter_watts channel from all three devices we have a breaking change for a lot of users because the sensor_power was created a long time after the initial database entry (I guess).
It seems that the sensor_power is sufficient for functionality, though …
Hi,
I’m having some trouble configuring things using the textual file format. I hope this is not something that has been answered elsewhere, couldn’t find anything similar.
// UZB1 as the zwave controller. Network key below censored
// secret key generated with python3.6: import secrets; secrets.token_hex(16).upper()
Bridge zwave:serial_zstick:controller [ port="/dev/ttyACM0", controller_master=true, controller_suc=true, security_inclusionmode=1, security_networkkey="B127961121631D9094A0F9A34071BC4F" ]
// Fibaro FGMS001 sensor
// Z-Wave Node 006: FGMS001 Motion Sensor
// FGMS001 Motion Sensor
// Motion Sensor
// Status: ONLINE
// zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
// zwave_class_generic GENERIC_TYPE_SENSOR_BINARY
// zwave_frequent false
// zwave_neighbours 1
// zwave_version 2.6
// zwave_listening false
// zwave_deviceid 4097
// zwave_nodeid 6
// zwave_routing true
// zwave_beaming true
// zwave_secure false
// zwave_class_specific SPECIFIC_TYPE_ROUTING_SENSOR_BINARY
// zwave_manufacturer 271
// zwave_devicetype 2048
// 14: (unused but UI default -1 is incorrect) BASIC ON
// 60: Temperature Report Threshold -> 0.1C
// 62: Interval of Temperature Measuring, seconds
// 64: Temperature Reports Interval, seconds
// group_1: status updates to node 1. node_NODEID_ENDPOINT_ID
// group_3: controller updates to node 1.
Thing zwave:fibaro_fgms001_00_000:controller:sensor_a (zwave:serial_zstick:controller) [ node_id=6, config_14_1=255, config_60_1=1, config_62_2=300, config_64_2=300, wakeup=300, binding_pollperiod=3600, group_1="node_1_0", group_3="node_1_0", nodename_name="Sensor A" ]
The sensor appears to come ONLINE actually even transmitting the data. However, it looks like the configuration does not go through.
When querying the thing configuration, using REST API
(http://myhost:8080/rest/things/zwave:fibaro_fgms001_00_000:controller:sensor_a), I have the following
"statusInfo": {
"status": "OFFLINE",
"statusDetail": "COMMUNICATION_ERROR",
"description": "Node is not communicating with controller"
},
"editable": false,
"label": "FGMS001 Motion Sensor",
"bridgeUID": "zwave:serial_zstick:controller",
"configuration": {
"group_1": [],
"group_3": [],
"group_2": [],
"nodename_name": "Sensor A",
"config_16_1": 0,
"wakeup_node": 1,
"config_12_1": 0,
"config_14_1": -1,
"config_64_2": 0,
"config_20_1": 15,
"config_40_2": 200,
"config_87_1": 28,
"config_62_2": 900,
"config_86_1": 18,
"config_42_2": 0,
"config_83_2": 1000,
"config_82_2": 100,
"wakeup": 300,
"config_60_1": 10,
"config_81_1": 50,
"config_80_1": 10,
"wakeup_interval": 7200,
"binding_pollperiod": 3600,
"config_1_1": 10,
"config_2_1": 15,
"config_6_2": 30,
"config_8_1": 0,
"config_9_2": 200,
"config_3_1": 1,
"config_22_2": 30,
"config_4_1": 2,
"config_24_1": 0,
"config_66_2": 0,
"node_id": 6,
"config_26_1": 0,
"config_89_1": 1
},
"properties": {
"zwave_class_basic": "BASIC_TYPE_ROUTING_SLAVE",
"zwave_class_generic": "GENERIC_TYPE_SENSOR_BINARY",
"zwave_neighbours": "1",
"zwave_frequent": "false",
"versionMax": "2.8",
"modelId": "FGMS001",
"zwave_version": "2.6",
"zwave_listening": "false",
"manufacturerId": "010F",
"manufacturerRef": "0800:1001,0800:2001,0800:3001,0801:1001,0801:2001",
"dbReference": "115",
"zwave_deviceid": "4097",
"zwave_nodeid": "6",
"vendor": "Fibargroup",
"defaultAssociations": "3",
"zwave_routing": "true",
"zwave_beaming": "true",
"zwave_secure": "false",
"zwave_class_specific": "SPECIFIC_TYPE_ROUTING_SENSOR_BINARY",
"zwave_manufacturer": "271",
"zwave_devicetype": "2048"
},
"UID": "zwave:fibaro_fgms001_00_000:controller:sensor_a",
"thingTypeUID": "zwave:fibaro_fgms001_00_000",
"channels": [
{
"linkedItems": [],
"uid": "zwave:fibaro_fgms001_00_000:controller:sensor_a:alarm_motion",
"id": "alarm_motion",
"channelTypeUID": "zwave:alarm_motion",
"itemType": "Switch",
"kind": "STATE",
"label": "Motion Alarm",
"description": "Indicates if a motion alarm is triggered",
"defaultTags": [],
"properties": {
"binding:*:OnOffType": "COMMAND_CLASS_SENSOR_BINARY"
},
"configuration": {}
},
{
"linkedItems": [
"Temperature_Sensor_A"
],
"uid": "zwave:fibaro_fgms001_00_000:controller:sensor_a:sensor_temperature",
"id": "sensor_temperature",
"channelTypeUID": "zwave:sensor_temperature",
"itemType": "Number",
"kind": "STATE",
"label": "Sensor (temperature)",
"description": "Indicates the current temperature",
"defaultTags": [],
"properties": {
"binding:*:DecimalType": "COMMAND_CLASS_SENSOR_MULTILEVEL;type\\u003dTEMPERATURE"
},
"configuration": {
"config_scale": "0"
}
},
{
"linkedItems": [],
"uid": "zwave:fibaro_fgms001_00_000:controller:sensor_a:sensor_luminance",
"id": "sensor_luminance",
"channelTypeUID": "zwave:sensor_luminance",
"itemType": "Number",
"kind": "STATE",
"label": "Sensor (luminance)",
"description": "Indicates the current light reading",
"defaultTags": [],
"properties": {
"binding:*:DecimalType": "COMMAND_CLASS_SENSOR_MULTILEVEL;type\\u003dLUMINANCE"
},
"configuration": {}
},
{
"linkedItems": [
"Battery_Sensor_A"
],
"uid": "zwave:fibaro_fgms001_00_000:controller:sensor_a:battery-level",
"id": "battery-level",
"channelTypeUID": "system:battery-level",
"itemType": "Number",
"kind": "STATE",
"label": "Battery Level",
"defaultTags": [],
"properties": {
"binding:*:PercentType": "COMMAND_CLASS_BATTERY"
},
"configuration": {}
},
{
"linkedItems": [],
"uid": "zwave:fibaro_fgms001_00_000:controller:sensor_a:alarm_tamper",
"id": "alarm_tamper",
"channelTypeUID": "zwave:alarm_tamper",
"itemType": "Switch",
"kind": "STATE",
"label": "Tamper Alarm",
"description": "Indicates if the tamper alarm is triggered",
"defaultTags": [],
"properties": {
"binding:*:OnOffType": "COMMAND_CLASS_SENSOR_ALARM,COMMAND_CLASS_BASIC;type\\u003dGENERAL"
},
"configuration": {}
}
]
}
(sometimes the node is offline, sometimes online. Presumably because it is battery powered. This is not an issue)
You can see that the configuration parameters in things (e.g. config_62_2=300, config_64_2=300), are not there.
What am I doing wrong?
Best,
Sami
It is currently not possible to configure the device if you are using textual thing configuration - sorry. This is something that is (slowly!) being added to ESH, but at the moment it’s blocked and there’s not really anything I can do to provide this.
Thanks for the very quick reply! OK so configuration must happen via UI – got it, although things can be “declared” in config file?
Is there a github issue that I can follow progress on this?
Best,
Sami
Correct…
Correct…
But (and here’s the killer)… You can’t use the UI to configure things that are defined in a config file.
Mainly this one - there have been many discussions in the past, but this is the issue to try and resolve the problem -:
You can also find some background here -:
1 Like
Any chance you could recompile with the latest database? I’m champing at the bit to get my Conexis L1 lock working 
Yep - I’ll do a build later tonight…
2 Likes
Thank you sir! Appears to be working just fine!
1 Like
am I the only one who has problems to change configuration of zwave controller via paperui? I’m only able to do it via habmin.
in paperui NodeID of “Controller is SUC or SIS and will receive updates from other controllers in the network” and NodeID of “The node ID is assigned by the controller and can not be changed.” are red marked, indipendent when I write something in the textfield.
also in paperui the textfield of “Controller is SUC or SIS and will receive updates from other controllers in the network” is empty (in habmin the value is 0)
As a general rule: Don’t change anything in z-wave things from paperui. It makes strange stuff with them. Do it from habmin.
I tried to include the Qubino HMNHDD (dimmer) securely but it appears to have included “regularly”.
Looking in the manual @ http://www.cd-jackson.com/zwave_device_uploads/210/Qubino-Flush-Dimmer-PLUS-user-manual-V1-6-2.pdf
Parameter No. 250 – Unsecure / Secure Inclusion
However this parameter does not show in Openhab? Could it be added? Any idea how this would work - include normally, set the parameter and then re-include securely?
What setting do you have for the Secure Inclusion Mode in the controller? Is it set to include all devices?
Would it be possible to make the parameter changes log entry a little more informative/readable?
2018-05-03 22:50:20.865 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=config_111_4, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]
This is not related to the binding… It’s in the core.
Ah okay, its not very important. Just had a aeontec techician looking thru my logs, when he informed me that maybe the param wasn’t set correctly (which it was) due to this log entry. And I can see where he’s coming from
This message is not at all related to the setting of the configuration - it’s about the configuration status only… It simply shows that the data has not been transferred to the device and is normal for all devices until the response is received to confirm the setting.
Secure inclusion for all devices. I have Fibaro dimmers included securely so it seems particular to this device (the Qubino HMNHDD).
In that case I’m not sure how this is meant to work - what does the manual say?
We can of course add any missing parameters to the database - that’s simple - but I’m afraid I can’t really comment on any device specifics.
I can say that IMHO Qubino make things very difficult with this sort of configuration. They do it quite a lot - enable a feature, exclude the device, then re-include the device so the feature is found…