I think the problem is this β¦ with your latest change the setHue values I send are getting set literally. But SmartThings uses a hue range 0-100 (which my setHues are based on) vs the hue standard of 0-360.
So, I send setHue 0: your driver sets to Red. All good.
I send setHue 31 which I expect to be green but with your latest driver I get orange. It should be 360/100 * 31 = 112 which is green.
I send setHue 67 which I expect to be blue but with your latest driver I get teal. But it should be 360/100 * 67 = 241 which is blue.
Does that help? If not, maybe just put the driver back to before all this. Or, maybe I can now send hue values based on the 0-360 range?
I donβt know what command sharp tools sends when you send setHue=31 to make it light orange.
I send setColor Hue=31 and setSaturation=100 and it turns green.
Of course, the color does not only depend on the hue, it also depends on the saturation.
In smartthings the RGB color sent to the device is always calculated by converting Hue and Saturation (values 0 to 100) to RGB values (0 to 255)
If you send setColor Hue=31 and setSaturation= 100 and it turns green.
If you send a setHue = 31 and setSaturation = 0 the color should be white, not green.
So itβs not me, itβs the lua libraries that control what is sent to the device and do the following.
If you only issue the setHue command this driver, the old and the stock does:
Looks in memory cache or last state of saturation and converts to RGB the commanded setHue value and the last setSaturation and sends calculated RGB values to the device.
I donβt understand why you only send setHue to establish a color, you will have your reasons, but I cannot test sending only setHue, I have put some debug prints to know that hue and saturation are being sent to the rgb conversion.
Send me a log sending a setHue command of 31 to see what hue and saturation are being processed in handler, in case there are any errors that I donβt see
βββββββββββββββββββββββββββββββββββββββββββββββββββ
Name Z-Wave Bulb Mc
Version 2023-03-08T12:37:59.125503937
βββββββββββββββββββββββββββββββββββββββββββββββββββ
This was the issue. My mistake. In the course of running various tests I had removed the setSaturation commands. Putting them back in colors are setting as expected again.
Iβm trying to make my FGBS-001 work with the new smartthings edge drivers and Iβve not been able to find any working oneβ¦ Iβve seen youβve uploaded some of the drivers you have to github but Iβm not able to find the source of the FGBS-223 in order to try to adapt that one to work with my deviceβ¦ Would you kindly point me out the location? I would gladly contribute it back to your repository whenever I get it working.
Thanks!
edit: BTW, Iβve tried to force the use off the FGBS223 versiΓ³n and it provides this traces when open and close are performed on one of the sensorsβ¦ but nothing happens in the UI:
2023-03-17T19:25:11.861064711+00:00 TRACE Fibaro Smart Implant BETA-4 Received event with handler unnamed
2023-03-17T19:25:11.862236045+00:00 INFO Fibaro Smart Implant BETA-4 <ZwaveDevice: 5cf1dcc2-a9ae-4616-bd7c-ab716fd0dc11 [3B] (FGBS001 - Movimiento y Salto)> received Z-Wave command: {args={value=0}, cmd_class=βBASICβ, cmd_id=βSETβ, dst_channels={2}, encap=βNONEβ, payload=β\x00β, src_channel=2, version=1}
2023-03-17T19:25:11.864086711+00:00 DEBUG Fibaro Smart Implant BETA-4 FGBS001 - Movimiento y Salto device thread event handled
2023-03-17T19:25:20.877298713+00:00 TRACE Fibaro Smart Implant BETA-4 Received event with handler unnamed
2023-03-17T19:25:20.886771379+00:00 INFO Fibaro Smart Implant BETA-4 <ZwaveDevice: 5cf1dcc2-a9ae-4616-bd7c-ab716fd0dc11 [3B] (FGBS001 - Movimiento y Salto)> received Z-Wave command: {args={value=255}, cmd_class=βBASICβ, cmd_id=βSETβ, dst_channels={2}, encap=βNONEβ, payload=β\xFFβ, src_channel=2, version=1}
2023-03-17T19:25:20.893279713+00:00 DEBUG Fibaro Smart Implant BETA-4 FGBS001 - Movimiento y Salto device thread event handled
Yes. I understood that no driver would workβ¦ But I was expecting to get the source of the smart implant to be able to change it myself in order to make it work (at least the sensor part) with my version. Iβve not made any edge drivers myself, so not having to start from scratch would be really helpful. Iβll wait for you to release the code. Thanks! Keep it up!
Iβve a working version for mine already only for the contacts. Key points are:
productType: 0x0501
local function process_contact_change_with_component(component, device, cmd)
if cmd.args.value == 255 then
device:emit_component_event(component, capabilities.contactSensor.contact.open())
else
device:emit_component_event(component, capabilities.contactSensor.contact.closed())
end
end
local function get_components(device)
return {
device.profile.components.main,
device.profile.components.second
}
end
local function handle_zwave_contact_change(driver, device, cmd)
local components = get_components(device)
process_contact_change_with_component(components[cmd.src_channel], device, cmd)
end
I guess it would be βeasyβ for me, when you release you FGBS-222 code to make a working copy for the FGBS-001 . I can live with my ugly (I really like what you did with the presentations) version till then. Thanks!
In this link is the smart Implant Beta-4 code.
There are the handlers of the On-off capabilities, they are not tested or I donβt know if they work when you invert the logic of out-1 and out-2 in preferences, before I used the ones from the default libraries
(New Version) Edge Driver Z-Wave Switch and Child Mc:
To facilitate the configuration of parameters and Association groups of the different Zwave devices and because when changing to the Z-Wave Device Config Mc driver to configure them, the routines and scenes that we have made are lost:
I have integrated the Z-Wave Device Config Mc driver inside the Z-Wave Switch and Child Mc driver as a subdriver
The subdriver configurator is executed by creating a Child device that will work exactly the same as the Z-Wave Device Config Mc driver, with the Options in preferences for:
- βDevice Fingerprint Infoβ
- βDevice Parameters Scanβ
- βDevice Parameter Configureβ
- βDevice Association Groups Scanβ
- βDevice Association Groups Configureβ
default: βDevice Fingerprints Infoβ
It is possible that the first time you have to clear the cache of the app to see the profiles of the child device configurator.
This allows you to configure device parameters and association groups, test if the device works with the new values without changing the driver and without losing routines or scenes
Once the parameters or association groups have been configured, it is convenient to delete the child device to ensure that the real devices work correctly, if they use configuration, association or version report handlers.
It is a BETA version, which I have tested with two different types of devices that I have, I would like more tests before replacing the current Mc version.
Please, if you find any error, tell me and I will try to correct it.
βββββββββββββββββββββββββββββββββββββββββββββββββββ
Name Z-Wave Switch and Child CONFIG
Version 2023-03-20T19:59:26.49339752
βββββββββββββββββββββββββββββββββββββββββββββββββββ
To use this driver you only have to make a driver change to the Z-Wave Switch and Child CONFIG version. No setting, routine or scene will be lost.
If everything works as expected, I will also integrate it into other drivers such as Z-Wave Sensor Mcβ¦
27 mar 2023 Update:
As it seems that there are no bugs reported merge with the Z-Wave Switch and Child Mc and the Z-Wave Switch and Child CONFIG will disappear.
The update will be done automatically in 12 hours maximum
βββββββββββββββββββββββββββββββββββββββββββββββββββ
Name Z-Wave Switch and Child Mc
Version 2023-03-27T15:26:34.151021779
βββββββββββββββββββββββββββββββββββββββββββββββββββ
(New Version) Edge Driver Z-Wave Sensor and Child Thermostat Mc:
As in Z-Wave Switch and Child Mc and since no one has reported errors, I have added the optional Child Device for Parameter Configuration and Association Groups subdriver to this driver.
If anyone wants to try it, I donβt have Zwave sensors.
Remember that in battery-powered sensors you have to wake up the devices for them to respond to to configure parameters and association groups configuration
This is the driver version Z-Wave Sensor and Child Thermostat CONFIG:
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Name Z-Wave Sensor and Child Thermostat Mc
Version 2023-03-23T15:50:09.35770828
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Hi, Im currently running the beta 4 driver for my smart implant device with 1 external probe.
The driver works fine in ST and shows the value of the external probe in the tile for the device. But in systems integrated with ST it is the internal sensor that are shown / sendt. Could you make the external sensor βprimaryβ ?
Sorry, that change in component and endpoint mapping would modify all other driver profile settings.
You can create a child device for ext temperature probe 1 with a single tile and use it for routines with third party applications that donβt see the child components.
Go to settings and enable preference βCreate Virtual Thermostat 1β
The virtual device will appear in the room in which the Hub is located.
It is a virtual thermostat, but if you leave it Off it only synchronizes the temperature of the external temperature probe 1
Hi,
I have a problem with Fibaro Switch Single module.
The status updated OK when using Smartthings App, BUT , does not chaged when toggling from the mechanical switch. I can see messages in CLI when logging this driver. The following is turn on and turn off log via mechanical switch.
I need you to confirm that the switch cable is connected to the S1 input of the physical switch.
The stock driver and mine expect a source endpoint of 0 or nil and the device is sending source endpoint=1
local function switch_binary_report_handler(self, device, cmd)
if cmd.src_channel == nil or cmd.src_channel == 0 then
SwitchDefaults.zwave_handlers[cc.SWITCH_BINARY][SwitchBinary.REPORT](self, device, cmd)
end
end
The S2 input is used to send scenes and therefore is not allowed by code to emit a switch state change.
If you confirm it, I will modify the code of my driver since these changes would affect more users.
On the other hand, if it is well connected, you should also report it to smsrtthings so that they can fix the stock driver.
Iβve got the same behaviour w this device and driver. As it sits in a remote location Iβm not able to use the CLI to make a log at the moment. It works well using the app and routines, but not using the physical switch. (The S1 is connected)