Z-Wave factfile Fibaro FGBS-001 Universal Binary Sensor
Posted: Friday 11 December 2015 11:35
Supplier:
Fibaro
Website:
http://www.fibaro.com/uk/support#
Function:
Universal Binary Sensor for 4 temperature probes DS18B20 and 2 discrete inputs
Z-Wave5
No
Superseded (?) by FGBS-321 version 1.2 and 2.1-2.3 (not sure of that! Not avail in NL?) Not sure if that one is Gen5.
Rebranding:
unknown, never seen
Device Library from http://www.pepper1.net
http://www.pepper1.net/zwavedb/device/514
Manuals from manuals.zwaveeurope.com and doc.eedomus.com:
manuals.zwaveeurope.com: PDF
doc.eedomus.com User doc PDF
DS18B20 sensor
Datasheet
Search the Chinese webshops for chip or wired versions. Less then 1.50 Euro (1 fail in a sample of 24).
DS18B20
All DS18B20 sensors do have an unique ID, therefor the DS18B20 sensors must be connected before Inclusion.
Replacing or adding a DS18B20? Exclude and Include again!
I have one working with 10 meter CAT5 cable, with remaining leads connected to Earth.
Hint: use aluminum tape to connect them with pipes.
Absolute accuracy reasonable, relative accuracy good (+/- 0.3C): adapt them in Domoticz.
Hint: tape them together for 24hr and correct step by step.
Resolution is great, 0.1C
Domoticz experience
Hardware: Remarks:
6 operational. For temperature no polling needed. For discretes: not sure, currently with polling.
(on my to do list to investigate: will feed 2 units with the same signal. With and without polling)
Polling results in OZW_log errors: Node005, ERROR: Dropping command, expected response not received after 1 attempt(s) ....in average 3x per hour
In the last 2 year they never lost their ID.
They give an average contribution to the Z-Wave network.
Configuration: Devices zwcfg_0xaaaaaaa.xml sample:
Conclusion
Unique and extreme small sensor capability.
Consumed input current not specified, but I have 3 running on one 12V 1.2A power supply.
I suspect that they are sensitive for ripple on the power supply (use an Elco!)
The weaker signal causes sometimes new strange values (like UV sensor data??). I think this is caused by the weak error recovering from Z-Wave.
This can cause pollution in the zwcfg_0xaaaaaaa.xml. In that case remove the node from the zwcfg_0xaaaaaaa.xml and let Domoticz re-discover it.
Not sure if polling is needed for IN1 and IN2 discrete inputs. Maybe Association Groups can do it better.
OUT1 and OUT2 are not controlled by Z-Wave! Only by IN1 and IN2.
They need to be embedded in a strong network.
Because of it's unique features: recommended.
But ... Superseded (???) by FGBS-321 version 1.2 and 2.1-2.3 (subsequent versions... that sounds like problems ??). Not seen avail. in NL.
Hope this helps
Domosapiens
[Edit: sanitized zwcfg_0xaaaaaaa.xml sample]
Fibaro
Website:
http://www.fibaro.com/uk/support#
Function:
Universal Binary Sensor for 4 temperature probes DS18B20 and 2 discrete inputs
Z-Wave5
No
Superseded (?) by FGBS-321 version 1.2 and 2.1-2.3 (not sure of that! Not avail in NL?) Not sure if that one is Gen5.
Rebranding:
unknown, never seen
Device Library from http://www.pepper1.net
http://www.pepper1.net/zwavedb/device/514
Manuals from manuals.zwaveeurope.com and doc.eedomus.com:
manuals.zwaveeurope.com: PDF
doc.eedomus.com User doc PDF
DS18B20 sensor
Datasheet
Search the Chinese webshops for chip or wired versions. Less then 1.50 Euro (1 fail in a sample of 24).
DS18B20
All DS18B20 sensors do have an unique ID, therefor the DS18B20 sensors must be connected before Inclusion.
Replacing or adding a DS18B20? Exclude and Include again!
I have one working with 10 meter CAT5 cable, with remaining leads connected to Earth.
Hint: use aluminum tape to connect them with pipes.
Absolute accuracy reasonable, relative accuracy good (+/- 0.3C): adapt them in Domoticz.
Hint: tape them together for 24hr and correct step by step.
Resolution is great, 0.1C
Domoticz experience
Hardware: Remarks:
6 operational. For temperature no polling needed. For discretes: not sure, currently with polling.
(on my to do list to investigate: will feed 2 units with the same signal. With and without polling)
Polling results in OZW_log errors: Node005, ERROR: Dropping command, expected response not received after 1 attempt(s) ....in average 3x per hour
In the last 2 year they never lost their ID.
They give an average contribution to the Z-Wave network.
Configuration: Devices zwcfg_0xaaaaaaa.xml sample:
Code: Select all
<Node id="3" name="Temp_A" location="" basic="4" generic="32" specific="1" type="Routing Binary Sensor" listening="true" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete">
<Manufacturer id="010f" name="FIBARO System">
<Product type="0501" id="1002" name="FGBS001 Universal Binary Sensor" />
</Manufacturer>
<CommandClasses>
<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="5" after_mark="true" mapping="48" setasreport="true">
<Instance index="1" endpoint="1" />
</CommandClass>
<CommandClass id="43" name="COMMAND_CLASS_SCENE_ACTIVATION" version="1" request_flags="5" after_mark="true">
<Instance index="1" />
</CommandClass>
<CommandClass id="48" name="COMMAND_CLASS_SENSOR_BINARY" version="1" request_flags="5">
<Instance index="1" endpoint="1" />
<Instance index="2" endpoint="2" />
<Value type="bool" genre="user" instance="1" index="0" label="Sensor" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="False" />
<Value type="bool" genre="user" instance="2" index="0" label="Sensor" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="False" />
<SensorMap index="0" type="80" />
<SensorMap index="0" type="83" />
<SensorMap index="0" type="172" />
<SensorMap index="0" type="175" />
</CommandClass>
<CommandClass id="49" name="COMMAND_CLASS_SENSOR_MULTILEVEL" version="1">
<Instance index="1" endpoint="3" />
<Instance index="2" endpoint="4" />
<Instance index="3" endpoint="5" />
<Instance index="4" endpoint="6" />
<Value type="decimal" genre="user" instance="1" index="1" label="Temperature" units="C" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="46.12" />
<Value type="decimal" genre="user" instance="2" index="1" label="Temperature" units="C" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="47.62" />
<Value type="decimal" genre="user" instance="3" index="1" label="Temperature" units="C" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="30.18" />
<Value type="decimal" genre="user" instance="4" index="1" label="Temperature" units="C" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="28.62" />
</CommandClass>
<CommandClass id="96" name="COMMAND_CLASS_MULTI_INSTANCE/CHANNEL" version="2" request_flags="1" mapping="endpoints">
<Instance index="1" />
</CommandClass>
<CommandClass id="112" name="COMMAND_CLASS_CONFIGURATION" version="1" request_flags="5">
<Instance index="1" />
<Value type="short" genre="config" instance="1" index="1" label="IN1 Alarm Cancellation Delay" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="65535" value="0">
<Help>Input I alarm cancellation delay. Additional delay after an alarm from input IN1 has ceased. The parameter allows you to specify additional time, after which the input no. 1 alarm is cancelled once its violation has ceased. Default 0.</Help>
</Value>
<Value type="short" genre="config" instance="1" index="2" label="IN2 Alarm Cancellation Delay" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="65535" value="0">
<Help>Input II alarm cancellation delay. Additional delay after an alarm from input IN1 has ceased. The parameter allows you to specify additional time, after which the input no. 1 alarm is cancelled once its violation has ceased. Default 0.</Help>
</Value>
<Value type="list" genre="config" instance="1" index="3" label="Type of input no. 1" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="1" size="1">
<Help>Type of input no. 1, what the input 1 will report if no contact is made. Default 1.</Help>
<Item label="Input NO (Normal Open)" value="0" />
<Item label="Input NC (Normal Close)" value="1" />
<Item label="Input MONOSTABLE" value="2" />
<Item label="Input BISTABLE" value="3" />
</Value>
<Value type="list" genre="config" instance="1" index="4" label="Type of input no. 2" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="1" size="1">
<Help>Type of input no. 2, what the input 2 will report if no contact is made. Default 1.</Help>
<Item label="Input NO (Normal Open)" value="0" />
<Item label="Input NC (Normal Close)" value="1" />
<Item label="Input MONOSTABLE" value="2" />
<Item label="Input BISTABLE" value="3" />
</Value>
<Value type="list" genre="config" instance="1" index="5" label="Type of transmitted control frame for association group 1" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="6" size="1">
<Help>Type of transmitted control frame for association group 1, activated via input IN1. The parameter allows to specify the type of alarm frame or to force transmission of control commands (BASIC_SET). Default 255 - BASIC SET.</Help>
<Item label="ALARM GENERIC" value="0" />
<Item label="ALARM SMOKE" value="1" />
<Item label="ALARM CO" value="2" />
<Item label="ALARM CO2" value="3" />
<Item label="ALARM HEAT" value="4" />
<Item label="ALARM WATER" value="5" />
<Item label="BASIC_SET" value="255" />
</Value>
<Value type="list" genre="config" instance="1" index="6" label="Type of transmitted control frame for association group 2" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="6" size="1">
<Help>Type of transmitted control frame for association group 2, activated via input IN1. The parameter allows to specify the type of alarm frame or to force transmission of control commands (BASIC_SET). Default 255 - BASIC SET.</Help>
<Item label="ALARM GENERIC" value="0" />
<Item label="ALARM SMOKE" value="1" />
<Item label="ALARM CO" value="2" />
<Item label="ALARM CO2" value="3" />
<Item label="ALARM HEAT" value="4" />
<Item label="ALARM WATER" value="5" />
<Item label="BASIC_SET" value="255" />
</Value>
<Value type="byte" genre="config" instance="1" index="7" label="Forced Level of Dimming group 1" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="255" value="255">
<Help>Value of the parameter specifying the forced level of dimming / opening sun blinds when comes "switch on" / "open" command to devices from association group no. 1. In the case of alarm frames the alarm priority is specified. Possible parameter settings: (1 – 99) and 255. Value of 255 makes it possible to activate the device when using the Dimmer module it means activating the device and setting it to the previous stored condition, e.g. when Dimmer is set to 30%, then deactivated, and then reactivated using command 255, it will automatically be set to the previous condition, i.e. 30%. Default 255.</Help>
</Value>
<Value type="byte" genre="config" instance="1" index="8" label="Forced Level of Dimming group 2" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="255" value="255">
<Help>Value of the parameter specifying the forced level of dimming / opening sun blinds when comes "switch on" / "open" command to devices from association group no. 2. In the case of alarm frames the alarm priority is specified. Possible parameter settings: (1 – 99) and 255. Value of 255 makes it possible to activate the device when using the Dimmer module it means activating the device and setting it to the previous stored condition, e.g. when Dimmer is set to 30%, then deactivated, and then reactivated using command 255, it will automatically be set to the previous condition, i.e. 30%. Default 255.</Help>
</Value>
<Value type="list" genre="config" instance="1" index="9" label="Deactivate transmission of frame cancelling alarm" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
<Help>Deactivating transmission of the frame cancelling the alarm or the control frame deactivating the device (Basic). It allows for disabling the deactivation function or the alarm cancellation function for devices associated with the appropriate input of the Fibaro Sensor. NOTE: Information concerning alarm violation or activation commands for devices from association groups are always sent. Default 0. ATTENTION: Information alarm triggered or command enabled for devices with associative groups are always sent. NOTE: Value "Group 1 not sent, Group 2 not sent" is only available in version 2.1 and up</Help>
<Item label="Groups 1 and 2 sent" value="0" />
<Item label="Group 1 sent, Group 2 not sent." value="1" />
<Item label="Group 1 not sent, Group 2 sent." value="2" />
<Item label="Group 1 not sent, Group 2 not sent." value="3" />
</Value>
<Value type="byte" genre="config" instance="1" index="10" label="Interval between successive readings of temperature sensors" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="255" value="30">
<Help>Interval between successive readings of temperature from all sensors connected to the device in seconds. Possible parameter settings: (1 – 255). Default 20. ATTENTION: taking temperature readings from the sensor does not result in sending a temperature condition report to the central hub.</Help>
</Value>
<Value type="byte" genre="config" instance="1" index="11" label="Interval between forcing to send report concerning the temperature conditions" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="60">
<Help>Interval between forcing to send report concerning the temperature conditions. The forced report is sent immediately after the next reading of temperature from the sensor, irrespective of the settings of parameter no. 12. Value 0 = Deactivates the function. Default 200. ATTENTION: Frequent sending of temperature condition reports is reasonable when the sensor is located somewhere where can occure rapid changes of ambient temperature. In other cases it is recommended to leave the parameter set to the default value.</Help>
</Value>
<Value type="byte" genre="config" instance="1" index="12" label="Insensitiveness to temperature changes." units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="8">
<Help>Insensitiveness to temperature changes. This is the maximum acceptable difference between the last reported temperature and the current temperature taken from the sensor. If the temperatures differ by the set value or more, then a report with the current temperature value is sent to the device assigned to association group no. 3. Intervals between taking readings from sensors are specified by parameter no. 10. Possible parameter settings:0 – 255 [0oC to 16oC] [0 oF – 28.8oF] In order to set the appropriate value of the parameter, the following formula should be used: x = delta T x 16 - for Celsius x = delta T x 80 / 9 - for Fahrenheit x – parameter value delta T – maximum acceptable temperature gradient in Celsius or Fahrenheit If the value is set to 0, then information about the temperature will be sent every time, immediately once the readings have been taken from the sensor. Default 8.</Help>
</Value>
<Value type="list" genre="config" instance="1" index="13" label="Transmitting the alarm or control frame broadcast mode" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
<Help>Transmitting the alarm or control frame in "broadcast" mode (i.e. to all devices within range), information sent in this mode is not repeated by the mesh network. Default 0. ATTENTION: If the broadcast mode of information transmission is activated for a given channel, then transmission of information in singlecast mode to devices assigned to the association group of this channel is deactivated.</Help>
<Item label="Sensor 1 and 2 Broadcast inactive" value="0" />
<Item label="Sensor 1 broadcast mode active, Sensor 2 broadcast mode inactive" value="1" />
<Item label="Sensor 1 broadcast mode inactive, Sensor 2 broadcast mode active" value="2" />
<Item label="Sensor 1 and 2 broadcast mode active" value="3" />
</Value>
<Value type="list" genre="config" instance="1" index="14" label="Scene activation" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
<Help>Enable/Disable scene functionality. The device offers the possibility of sending commands compatible with Command class scene activation. Information is sent to devices assigned to association group no. 3. Default 0.</Help>
<Item label="Scenes disabled" value="0" />
<Item label="Scenes enabled" value="1" />
</Value>
</CommandClass>
<CommandClass id="114" name="COMMAND_CLASS_MANUFACTURER_SPECIFIC" version="1" request_flags="5">
<Instance index="1" />
</CommandClass>
<CommandClass id="133" name="COMMAND_CLASS_ASSOCIATION" version="1" request_flags="5">
<Instance index="1" />
<Associations num_groups="3">
<Group index="1" max_associations="5" label="Input IN1" auto="true" multiInstance="true">
<Node id="1" />
</Group>
<Group index="2" max_associations="5" label="Input IN2" auto="true">
<Node id="1" />
</Group>
<Group index="3" max_associations="1" label="Temperature Sensor(s)" auto="true">
<Node id="1" />
</Group>
</Associations>
</CommandClass>
<CommandClass id="134" name="COMMAND_CLASS_VERSION" version="1" request_flags="5">
<Instance index="1" />
<Value type="string" genre="system" instance="1" index="0" label="Library Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="3" />
<Value type="string" genre="system" instance="1" index="1" label="Protocol Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="3.52" />
<Value type="string" genre="system" instance="1" index="2" label="Application Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="2.01" />
</CommandClass>
<CommandClass id="142" name="COMMAND_CLASS_MULTI_INSTANCE_ASSOCIATION" version="1" request_flags="5">
<Instance index="1" />
<Associations num_groups="0">
<Group index="1" max_associations="5" label="Input IN1" auto="true" multiInstance="true">
<Node id="1" />
</Group>
<Group index="2" max_associations="5" label="Input IN2" auto="true">
<Node id="1" />
</Group>
<Group index="3" max_associations="1" label="Temperature Sensor(s)" auto="true">
<Node id="1" />
</Group>
</Associations>
</CommandClass>
<CommandClass id="156" name="COMMAND_CLASS_SENSOR_ALARM" version="1" request_flags="2">
<Instance index="1" endpoint="1" />
<Instance index="2" endpoint="2" />
</CommandClass>
</CommandClasses>
</Node>
Unique and extreme small sensor capability.
Consumed input current not specified, but I have 3 running on one 12V 1.2A power supply.
I suspect that they are sensitive for ripple on the power supply (use an Elco!)
The weaker signal causes sometimes new strange values (like UV sensor data??). I think this is caused by the weak error recovering from Z-Wave.
This can cause pollution in the zwcfg_0xaaaaaaa.xml. In that case remove the node from the zwcfg_0xaaaaaaa.xml and let Domoticz re-discover it.
Not sure if polling is needed for IN1 and IN2 discrete inputs. Maybe Association Groups can do it better.
OUT1 and OUT2 are not controlled by Z-Wave! Only by IN1 and IN2.
They need to be embedded in a strong network.
Because of it's unique features: recommended.
But ... Superseded (???) by FGBS-321 version 1.2 and 2.1-2.3 (subsequent versions... that sounds like problems ??). Not seen avail. in NL.
Hope this helps
Domosapiens
[Edit: sanitized zwcfg_0xaaaaaaa.xml sample]