Bridge info

Registering a bridge, is described here.

Scan new lights

Pressing this button will start a new scan for lights on the bridge. The plugin will wait for the bridge to discover lights and will recheck the bridge within 2 minutes. Normally you do not need to press this button. The scan is done every 15 minutes by the plugin itself. When adding new lights, the plugin should find them somewhere in the next 15 minutes.

Updating firmware on a bridge

If an update is available for a bridge, the plugin will show a red text on this block to notify you of the update. You can initiate the update through the plugin by pressing the button “Update” on this page. This button will not be shown if no update is available.

With this button you can tell the bridge to do a forced include of lights. This way you can add a foreign light, that is registered as member of a different bridge to your bridge. To do this you need to bring the light to be included very close to the bridge (15 cm/6 inch). Then press the button on the configuration page. If the light blinks a few times, the light has been succesful included in the bridge.

Standard settings for lights

Polling frequency

With this parameter you can set the frequency of polling the bulbs for changes. The value given here is in seconds. Be aware to not set this value too low as it might flood your network or your bridge. In my current situation 2.0 seconds works very well even with other apps doing their thing with the lamps in high speed, but this all will depend on the number of bulbs you have as well as the speed of your local network.
Note: This setting is ignored when using a deCONZ gateway and the webhook is set. In this case you will see a remark in the log like ““Refresh bridge xxxxxxx set to 30 seconds after establishing direct connection”” From here on the polling frequency for bridge xxxxxxx is ignored

Standard transition time

With this value you can set a standard transition time when dimming command or on command is given. This will enable a gradual change for the lights. Transition time is shown in tenths of seconds. It is known that when you use a transition time and a light has been powered on - but the light itself was off - the transition will start from the last used color setting.

Standard dimming value change

This is the value change used when the down or Up buttons on the bright devices for lights or groups are pressed. Depending on the button used this value is used as positive or negative value.

Standard hue value change

This is the value change used when the down or Up buttons on the Hue devices for lights or groups are pressed. Depending on the button used this value is used as positive or negative value.
Note: If the value of the hue device is raising higher then the maximum hue level (65535), or dropping below 0, the Philips Hue Bridge will correct this and cycle through the hue range without issues.

Standard saturation value change

This is the value change used when the down or up buttons on the saturation devices for lights or groups are pressed. Depending on the button used this value is used as positive or negative value.

Standard duration colorloop deCONZ devices

This option is only visible when a RaspBee/ConBee gateway is found. A colorloop command to lights connected to this gateway can have a preconfigured duration for the colorloop. Here yu can set the standard value for a colorloop. In the JowiHue action you can differ from this standard setting. Accepted values are 1 to 255, where 1 is very..very fast, and 255 would then be very..very slow.

Use percentage for dim values instead of standard values

If you want, you can show the devicevalue for dimming in percentages instead of the standard values fom 1 to 254. It seems that the alexa device of Amazon needs this.

Use Kelvin values instead of Mired colour temperature

If you want, you can display the kelvin colour temperature on the CT devices of the plugin, this could feel more familiar then the Mired values used by the bridges.

Enable Can_Dim for light

On the forum I understood that this option on the devices is needed to correctly communicate with the alexa device. I am missing a confirmation if this really helped, so is anyone could confirm this makes a difference, let me know?

Miscellaneous options

Show Lux values on lightlevel devices

Set this option to recalculate the Lux values from lightlevel devices.

Disable upgrade bridge checks

Enabling this option will stop the plugin from checking for upgrades of the bridges. It will not stop any other app from checking, but will prevent showing the upgrade button so you cannot upgrade by accident without knowing the consequences. Enabling this option will also disable the notification device option.

Use a device for notifying bridge updates

Enable this option to create a virtual device for notifying for bridge updates. When a update is available for any of the bridges, the device string is set to a descriptive string about the update. With events you can then perform notifying steps based on value and string of the device.

Use Colorpicker on Hue enabled devices

By default this option is enabled. When enabled it will show the colorpicker on the deviceutility page of the HomeSeer webpages. It became clear that this jquery element can slow down the build of the deviceutility page considerable when there are many Hue lights in the system (40 +). Disabling this option will regain speed again for the deviceutility page.

Use only group devices for Luminaires

This option only shows when you have Luminaires connected to (one) of your Hue bridges. Enabling this option will remove the LED's in the luminaires from the devices and control the Luminaire on group level. You still can address the leds through scenes.

Hide bridge groups bound to sensors

This option is available when a deCONZ gateway is available. deCONZ will create a new group when a sensor is added. This group is also assigned to the sensor. In Homeseer this group is most often not needed as you might want to use the sensor to control other devices then only Zigbee devices. With enabiling this option, the groups assigned to the sensors will not create a new device.

Show bridge details for lights or sensors on device property page

This option is enabled by default. Is showing bridge details for a sensor or light that can be send to the plugin owner when en new model light or sensor is used.

Logging options

In this block of options you can set how the plugin should do its logging. For normal operation all options should be off, to make sure performance is maximised when running.

Enable debugging

Enabling this option will send debug info to the HS3 log. This level gives you a bit more insight on the processes the plugin is running, which might help you in a basic analisys if all is running correctly.
Settig this option will send all debug information to the HS3 log. If also Logging to console and/or logging to file are enabled, the log will be replicated also to these areas.

Enable deep tracing

Enabling this option will send detailed information on processes to the console or plugins log file. Because of the amount send, this logging is not send to the HS3 log to save some performance. Enabling this option will automatically disable the debug option as it is included in this option. This option should be used only when requested by the developer as this is taking a performance toll.

Send log to console

If enabled, the log will be send to the developers console in HS3 when enabled in the manage plugins page. A restart of the plugin might be needed to see the console after enabling it.

Send log to file

If enabled all logging will also be send to a log file. When using the deep trace option, this option should also be used, so the file can be send to the plugin owner to analyse if needed. The log created is placed in the \logs subdirectory from the HS3 installation directory. When the plugin is restarted the current log file is renamed to JowiHue-last.log to prevent the log to be lost with a restart.