I tried this setup with an IKEA plug (instead of a bulb) and it did not work. When I pair it directly with the remote (long 10s press), the plug lost its connection to Hubitat. Same when pairing it with Hubitat (4 presses in 5 seconds), it lost connection to the remote.
You need to pair both to the Hubitat Hub, then you have 2 options:
Use specialized Hubitat apps (Button Controller, Rule Machine, etc.) to act as the middle man: it listens for remote button pushes, and sends commands the bulb (on/off, dim up/down, etc.). This is the standard setup. Both devices "talk" only to the hub. The only disadvantage is that, if the Hub is offline (updating/restarting/powered off), nothing will work since the middle man is "dead".
Use Zigbee bindings, so that the remote sends commands directly to the bulb (through the mesh). Not all IKEA remotes support this feature, only those that work as on/off or "dimmers". This is not very used in the Hubitat world mostly because we don't have an app (or support in the IKEA drivers) to help with the initial bindings setup. Advantage is that, once the bindings are in place, the remote can control the bulb even if the Hubitat Hub is offline.
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.
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...
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.
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..
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.
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:
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.
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?
I'll try to explain:
