There is not a way to select files from a bundle in the HE UI. You can always edit the bundle on a computer and then import. Now this said a dependent file might be excluded that the driver you need depends on. Just look at the import declarations at the top of the driver as you are editing the zip.
Import declarations are not the only dependencies. Child devices are not listed on the import section. Driver uses few custom child device drivers (due to the lack of some features in built-in Virtual/GenericComponent devcies)
1 Like
Does this mean I have to install everything?
Can I then delete an unused things or better not to?
You may delete other vendor driver keeping Shelly driver and virtual/generic component drivers.
Bundle contents may be edited directly on the hub (you can exclude drivers from installed bundle). While they are in bundle they should be deleted with bundle if one being deleted.
In any case all the bundle content is wrapped inside namespace and will not interfere with other drivers.
OK, I installed the entire Bundle and everything is working just fine. Thank you!
Are you saying I can delete Heatit Thermostat. Aeotech and Fibaro drivers (these never will be used) without any problems? Or better not to touch anything because they are not doing anything if not used?
It is safe to delete them. Tho they will most probably reappear on bundle update.
I am testing Shelly Plus RGBW device.
Driver (Shelly Plus/Pro xPM) picked up all inputs (even the one which is configured as analog). All inputs are working just fine and as expected.
However RGBW controls are near 100% Brocken.
On/Off commands are working for all 4 channels all together (it looks like as intended).
Set Level (on the left side of Set Saturation button) works only for the RGB channels.
Start/Stop Level Change buttons are working for all 4 channels (again, it looks like as intended).
All other button are not doing anything at all. As a result changing color is impossible.
Shelly embedded web interface allows to control individually each channel:
Is it possible to update/modify a driver and have individual per channel control?
This is/will be very desirable/preferrable option for controlling this device.
Frankly I never could understand why basically all drivers for RGB(WW) devices are trying to be too smart. Naturally all color strips/bulbs are based on the RGB(WW) physical LEDs. So, having individual per channel control is very natural. All that mess with color settings belongs to the upper level app (not driver).
Sorry for inconviniece.
A RGB and RGBW profiles support is incomplete. I can try to finish it. Tho I'm lacking the device itself for proper implementation and testing. It will need some iterations with feedback without device at hand.
As for individual channels - this mode is expected to work. There should be profile selection option on the device itself (Shelly web interface). After changing to the separate channels profile device should work as 4 independent dimmers. And driver should spawn child devices accordingly after pressing 'Configure' on the device with active profile.
Profiles them selves are mentioned here Shelly Plus RGBW PM | Shelly Technical Documentation
- 4 instances of Light (
light:0,light:1,light:2,light:3) in light profile - RGB (
rgb:0) in rgb profile - RGBW (
rgbw:0) in rgbw profile
This is from different device. But I assume it should be the same for Shelly Plus RGBW PM
Light components (dimmers) are supported without channel limits. So it should just work the same way as for devices with less channels
If you mean additional per channel controls for RGB and RGBW profiles - I can extend it.
The RGBW profile is tricky to implement properly specifically due to the W channel. The math it self is trickier to mix in W channel and adjust RGB part for a specific hue. It basically needs to detect what amount of target color can be deliwered with W component and augment with RGB the rest. As such it needs to know W component temperature (as a user adjustable setting) and the same way it is desired to know RGB part white (all to 100%) color tempreature (usually 6500K for RGB leds)
Actually my device is Shelly RGBW PM (not Plus).
Yes, 4 individual channels mode is working as expected. For whatever reason 4 Temp Sensors are created. All 4 reported the same Temp. I guess, this is internal IC Temperature in F (reading is 120.9 it is just a number, no unit). Temp reporting is very welcome but it should be only one
Temp child device, not 4 (better to be corrected but this is not a big deal).
As I already mentioned, all these color calculations and tricks for the color/color temp settings should/must not be done in Driver. This is job for the app. Driver should/must provide only a controls for the individual channels. Almost the same as it done in individual channels mode. White (W) channel ALWAYS must have an individual control. In RGB(W) mode On/Off Switch should/must control RGB channels in one shot and Channels 0, 1 and 2 simply should be marked as R, G and B respectively. Color Picker is desirable but not really necessary. This is exactly what Shelly app is doing.
My current use case is to use just one Light Channel and 3 Sensors (2 digital and 1 analog). Current driver version is perfectly fine "as is". But it will be nice to have RGB(W) mode fixed.
I can wait a bit with deploying this device and sure, can test the updated driver(s) and provide you feedback.
Yes. A single temp sensor is more logical. On this note the driver is generically reacting to what device provides.
A bit of internal kitchen: Shelly is using component approach. I.e. all their Gen2+ devices have features split into components. Thus my driver is reacting not to a particular devices but to a surveyed list of features (components) device reports (and driver has support for). The multiplication of temp sensors is directly related to the point where each 'light' component instance (one per channel) has temperature reading. And there is no way to identify if device will report the same value or different.
It is not surprizing that small device just copies the inner temp sensor for each channel. I may assume bigger brothers like Pro Dimmer 1 and Pro Dimmer 2 have one sensor per triac inside.
But missing temperature unit is probably a bug. Need to check it.
As for per-channel control in RGB/RGBW modes - many options of control are possible. For simplicity I'll check built-in child devices for RGB and RGBW functionality (regarding controls they are providing). Right now the driver is mainly forwarding control signals to the device. But not all commands might be currently implemented. I'll try to force driver to spawn fake child devices locally and test for what is missing.
As for channel naming - in 'light' profile mode they are just independent channels. That is why the color abbreviations are not applied.
But you are free to edit name and label manually. The driver is not using names nor lables for operation (it is using so called network ids inside). Names and labels wiil be retained unless child device is deleted (for example due to profile change for one that has no such child devices)
Thank you very much for the Shelly implementation details.
This looks like a very good approach. This way the driver will try to pickup whatever is available and supported. I wish, all drivers are designed this way.
Yes. The only little problem is - in the "virtual" RGB mode it will be 4 individual on/off switches. This could be "fixed" with an extra small rule (not a big deal) but better to have a built-in virtual switch with the ability to select which channel to add for the combined on/off control.
@dmitry.rozovik
These warnings in the log are from Shelly I4 DC device:
What is unconfigured and where?
How do I fix this (minor) issue?
You seem to have added a shelly script. It might be related to bluetooth devices.
Driver sees its activity but no child device to forward to.
Just press 'Configure'. Corresponding child device will be added.
These child devices are 'switch'-like allowing to start/stop script, showing if script is running and allow to get custom messages from script if needed.
ble_scan_result will be ignored as script child devices listen for specific events. Those are listed in the sample script on a hubitat device page. Scripts may send events to the hubitat driver child devices. Tho there is no custom events from child device to shelly script yet.
It is possible to make 'issue-once' scripts that do some job and exit. Then by adding such child to a dashbord as a tile you will be able to start it (like some virtual button) and see if it is still running (like pump out some water for 5 minutes or until some sensor indicates it's time to stop). It's not an RM rule, it's a shelly script (directly on a device it self) that may work autonomously as some distributed task
You are 100% right.
Shelly I4 DC has a BLE related script added.
Your advice took care about this warning. Thank You!
Right now I have two active Shelly devices: Shelly I4DC and Shelly RGBW PM (few more will be added). As far as BLE configuration both configured the same way but Shelly RGBW PW does not have any scripts added/running.
Talking about Shelly BLE Gateway. I have running Home Assistant instance, Shelly devices suppose to provide a BLE Proxy sevise. But no matter what I tried (played with various Shelly and/or HA configurations) I cannot get it working. Could you please advice hoe to configure Shelly Device(s) and HA Shelly Integration(s) in order to get BLE Proxy working?
AFAIK there are two types of Gen2+ devices: with BTHome feature (Shelly Pro and Gen3+) and without it (Shelly Plus). Both can communicate with bluetooth devices and forward readings to the Shelly Cloud Service. The main difference is that BTHome feature is more hight level (manages binding and virtual sensors inside shellies simplifying driver code).
To handle pre-BTHome devices there should be ether a script or script+driver/app that filters out BT device MAC addresses (those hex numbers with semicolons after every second digit in your log screenshot) and decodes their message payload.
For BTHome devices a driver needs to handle BTHome virtual device events.
Shelly RGBW PM is actually this one Shelly Plus RGBW PM – Shelly Europe
(My driver supports only Gen2+ devices. And your device is definitely not a 'Pro' one)
It's a pre-BTHome device. And you have some script installed. So if it is Home Assistant integration, HA should handle (decode and translate BT messages to its virtual devices).
In my driver there is no functionality for this atm. BT part is not implemented.
Tho it is still possible to do with custom script by parsing BT payloads directly on the device and sending custom data from shelly script to HE child script device instance. It's just not that user friendly (needs knowledge on shelly scripting and shelly BLU data format)
BTW I can see a 'bigger brother' Shelly Pro RGBWW.
Shelly Pro RGBWW PM – Shelly Europe
5 channels and more profiles
- light x5
- rgb + cct (3 + 2)
- cct + cct (2 + 2)
- rgb + light + light (3 + 1 + 1)
cct component is not currently implemented in my driver. Seems to be pretty recent addition.
Interesting. So, Shelly Cloud is in the middle? This is not what I red about Shelly BLE Gateway feature. According to may different articles/videos this must be 100% LOCAL BLE Forwarding service. I don't like anything cloud-based all together. So, it looks this Shelly BLE Gateway in my case is "no go". I did install two HA BLE Proxy and they are working very well. Since I have few BLE-enabled Shelly devices it will be nice if they also can be configured as a 100% local BLE Proxies. Am I missing something?
Mmm.. cloud service is not exactly in the middle. Rather as one of the destinations it handles BLU messege decoding.
And local custom decoding is also possible as an alternative. In case of HA the latter one handles it.
I also prefer to avoid cloud services. And it is one of the reasons I like Shellies.
