@dandanache,
Please see warning message below:
1 Like
From r/tradfri, I found out that PARASOLL (that was released in late December in EU) just hit the US stores. So I would expect a similar delay for BADRING, but don't take my word for it.
Thanks for reporting this! It's a feature not a bug 
I'll try to explain:
On each event that the driver receives, it checks if the driver version matches the "lastCx" state variable. If there is a mismatch, it automatically calls "Configure" for you, and then updates the "lastCx" state variable (so it doesn't happen on every event). You probably updated the driver from 3.8.0 to 3.9.0 and triggered this behavior.
This was done so that when folks change the driver to one of ours, it will auto-configure the device (setup the correct Zigbee binds and attribute reporting, clear the scheduled jobs of the previous driver and setup ours, cleanup state variables, etc). Most of us don't know or forget to click the "Configure" button after a driver change, so the driver tries to be smart about it
It might also be helpful when upgrading to newer driver versions, if new functionality is added that requires more binds/reports/jobs/etc; this is not the case for 3.8.0 -> 3.9.0 but calling configure should not break anything.
2 Likes
Thanks for the explanation - amazing work!
1 Like
Thank you, I will go for option 1.
I tried to import driver for Rodret Dimmer (https://raw.githubusercontent.com/dan-danache/hubitat/master/ikea-zigbee-drivers/E2201.groovy), but when saving I get this error message: No signature of method: Script1.definition() is applicable for argument types: (java.util.LinkedHashMap) values: [[name:Tile Builder - Attribute Monitor, description:Monitors a single attribute for a list of devices. Publishes an HTML table of results for a quick and attractive display in the Hubitat Dashboard environment., ...]] on line 82
What am I missing?
I don't have any issues with the other 4 drivers that I have imported from here
Apparently I did something differently on mobile. Imported using PC without any issues
This is a weird error but I don't think it has anything to do with importing the E2201.groovy file. Looks like something related to [RELEASE] Tile Builder - Build Beautiful Dashboards. Maybe you took a wrong turn somewhere...
You can find the official documentation with the steps to manually install a custom driver here: How to Install Custom Drivers | Hubitat Documentation.
Hope this helps.
Are you getting that error from running Tile Builder. The line it references is just part of the program definition and would be an unusual place for one person to get an error and others not get it. Can you give more context.
1 Like
I figured out that I must had been done something wrong on mobile. Did it on PC.
Now I just have to figure out how to setup dim behavior. I guess I must use a custom app for this. Correct?
You are right. The driver just tells Hubitat that this button was pushed, that one was held/released, etc.
You must now use apps (Button Controller, Room Lighting, Rule Machine, etc.) to instruct Hubitat what actions to execute when those buttons are pushed.
@dandanache
Do you have any idea what these error messages mean? I get one from each of my Tradfri Control Outlets every time my Hubitat reboots. Other than that, they seem to function completely normally..
1 Like
They are "Mgmt_Rtg_rsp" commands, probably Hubitat asks for this information but forgets to filter the responses from the device and forwards them to the driver. Like you said, they have no impact on the device normal operation so I added them to the "ignore" list. Will be fixed in the next version.
Thank you for the report!
Hello
I just saw this on a TRADFRI 30W LED Driver using your driver version 3.8.0 :
First time I see this message. The log came in as the hub was starting up after a reboot (similar to what @a.mcdear observed, it seems).
1 Like
First time I see it too. I looked it up and it is a Parent_annce_rsp message, so again something that does not affect the basic functionality. Just the device following very strictly the Zigbee specs. Will also be added to the ignores list in the next version. Thank you for the report!
As as side note, with my last visit at IKEA, I picked up 10 x Shortcut Buttons (E1812) since IKEA is getting rid of them. I got them for cheap at about 3$ a piece. Here are 3 of them playing nicely and patiently doing their firmware updates:
Are those the TRÅDFRI buttons? My local IKEA has them for $10.99 (Last chance to buy).
I'll have to keep an eye on things...
Yep, TRÅDFRI buttons. IKEA is removing all products that use non-rechargeable batteries (e.g. CR2032 coin cells). The TRÅDFRI button was replaced by SOMRIG that uses AAA batteries. I believe that TRÅDFRI buttons are the last to go.
On my local IKEA website, these were "last change to buy" at full price, for some time. When they introduced the new SOMRIG, they pulled the TRÅDFRI buttons from the site and from the shelves. I got them from the "as-is zone" (usually near the checkout lanes) where they sell returned and end-of-line products at good discounts.
1 Like
Thanks! For me, SOMRIG is still $1 less (but I'll check that as-is area next time I'm there).
1 Like
@dandanache awesome drivers
How is it about firmware update?
Is it possible to see if there is an update for an IKEA device?
Is there a flag been set or some kind of notification, so it is possible to see that an update is awailable?
Would it be possible to do that?
Kindly regards Rasmus
When you click the "Update Firmware" button, on the device details page, the following happens:
-
The Hubitat hub sends a Zigbee message to the device saying something like "You should check for firmware updates".
Note: battery powered devices might not get this message since they are sleeping almost all the time, so you should "activate" them (push a button, trigger motion, etc) in order to make sure they are awake. -
The device sends a message to the hub saying "This is the firmware version I'm currently running on. Anything new?"
Note: this is when the hub learn the device firmware version and populates the "firmwareMT" value in the "Device Details" section. -
The hub then connects to the Hubitat cloud servers and checks if the staff uploaded there a firmware file with a version that is newer than the one received in the previous step.
-
The hub replies with either "No updates for you" and the message exchange stops; or the hub says that it has this new version, and then the device starts downloading the firmware file.
To see what is really happening, you need to click the "Update Firmware" button and watch the Live Logs for messages coming from the hub (sys:1):
This is how the Zigbee specification handles OTA updates and the hub implemented it as best as it could. That being said, the process is indeed not user friendly. Folks click that damned button and nothing happens, then probably click it a couple of times more, for a good measure, and finally conclude that "it's not working, probably broken... oh well...".
I would say that this needs to be added in the platform. I mean, it kinda works if you know how the platform handles firmware updates and know where to look at. But it definitely needs some UX love.
I'm pretty sure a "Zigbee Firmware Updater" app can be coded that can send the first message to all Zigbee devices, monitor the logs websocket for replies from sys:1 and present the information in a user-friendly way. Doable but hackish
1 Like
I indeed managed to successfully re-pair a stubborn Aqara T/H sensor directly to the hub (C7) from its final location using this tool. Thanks, @dandanache !
1 Like
I salute you for using it and managing to come out on top of it 
I used it recently for an IKEA device and, oh man... I had to read the instructions (that I wrote) twice.
6 Likes
