Tradfri dimmer

Yeah, that's what I was afraid of. For all the reasons I posted above, there's nothing that can be done to get it to transition more gracefully for your GE Dimmers. Set level for those is an instant change.

I might try them as a seitch vs dimmer. Or try a different dimmer. Was looking for a resonnto try zooz.

1 Like

The dimmer is very jittery. more due to just how sensitive these little buggers are. I do prefer them as a switch, as this is much easier to use day to day.

But even as a switch, you only need to twist them a little for them to work. Too fast, and it can be too much :+1:

Ok, I've been playing with the puck for a couple days. Such an interesting device. Very Swedish.

Here's the short version for anyone who doesn't want to read a technical post: The driver needs some updates to make it work well as a dimmer control in Hubitat. I'm working on it now.

Now, the long version:

So interesting that they are magnetic! I wasn't expecting that. So Swedish.

You don't actually have to use them on the magnetic base. They work by measuring an internal accelerometer. (This ends up having some implications. The internal firmware is having to make a determination about your accelerometer movements to decide whether you intend to fade, or you intend to switch on/off. So you have to train your hand a little bit to make the two types of motions distinct.)

I tested it out using both the switch and dimmer drivers posted above. I believe @Royski converted them over from work someone else had done on Smartthings?

I found that the switch driver worked pretty well. To do an on or off, I had to make a fast/big motion on the puck. Once I got used to that motion, the puck was 99% reliable, and if I used Switch Bindings to bind it to one of my smart switches, it worked very well.

The dimmer driver didn't work so well. Here's what I found:

  • Big/fast motions for on/off mostly worked.
  • Slow or small fade motions were hit and miss. Even if I got rid of Switch Bindings and just watched the device page for the puck, its level changes did not seem to match what I expected. Sometimes it would go up or down, and sometimes it wouldn't. And if I very smoothly kept turning it, it would make one fade step and then not continue fading.
  • Then I started looking at the logs and saw the same thing.
  • So then I started debugging the driver code so I could follow its flow.
  • That's when I discovered that the puck is not sending messages continually as you slowly turn it. It sends one message when you start turning it, and one message when you stop turning it!

Presumably, since IKEA intended the puck to be bound directly to one of their bulbs, their bulb firmware is interpreting these start/stop commands in a satisfactory way, but the existing Hubitat driver was only using the start command to initiate a level step, and it was ignoring the stop command. This resulted in it only continually fading if you did lots of little start/stop movements with your hand.

So anyway, I'm working on the driver to make it continually fade up/down until you stop turning the puck.

1 Like

Update: I worked on the dimmer driver for a while last night and made a lot of progress. It's getting close and just needs a little tuning.

1 Like

Many thanks for your help on this :+1:
I'm still using many of these little pucks, but they are so, so jumpy as a dimmer, although I got by with them :wink:

Having a better driver would be awesome!

Ok, I have a first version ready! Can you try this out and let me know how it works for you?

3 Likes

I just paired one up, but not getting dimming.
Any tips?

dev:61172019-12-23 16:23:42.191 debug[raw:catchall: 0000 0006 00 00 0040 00 A91C 00 00 0000 00 00 01FDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:A91C, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[01, FD, FF, 04, 01, 01, 19, 00, 00]]
dev:61172019-12-23 16:23:42.186 warnDID NOT PARSE MESSAGE for description : catchall: 0000 0006 00 00 0040 00 A91C 00 00 0000 00 00 01FDFF040101190000
dev:61172019-12-23 16:22:21.584 warnEVENT [name:battery, value:17.0]
dev:61172019-12-23 16:21:51.632 warnEVENT [name:battery, value:10.5]
dev:61172019-12-23 16:21:19.623 debug[raw:catchall: 0000 0013 00 00 0040 00 A91C 00 00 0000 00 00 811CA92DDE2CFEFF570B0080, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:A91C, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[81, 1C, A9, 2D, DE, 2C, FE, FF, 57, 0B, 00, 80]]
dev:61172019-12-23 16:21:19.620 warnDID NOT PARSE MESSAGE for description : catchall: 0000 0013 00 00 0040 00 A91C 00 00 0000 00 00 811CA92DDE2CFEFF570B0080
dev:61172019-12-23 16:19:48.540 warnEVENT [name:battery, value:8.0]
dev:61172019-12-23 16:19:03.035 debugConfigure
dev:61172019-12-23 16:19:00.039 warnClearStates(): Clearing device states
dev:61172019-12-23 16:18:33.406 warnEVENT [name:battery, value:30.0]

Weird. I'll have to look into that. It's worked for @macdenewf and me, but I can think of a few possibilities:

  • different firmware on different pucks
  • some kind config/initialization step that happened on ours but not yours yet.

I'll dig into what those codes in your log mean.

1 Like

Ok, scratch that. I Reset and re-paired without removing and then hit configure.
Also commented back in some debug messages to see better. Now its working :+1:

Very smooth action!! Well done on that, its very, very good :smiley:

dev:61172019-12-23 17:00:41.067 debugiterate: stopped 100
dev:61172019-12-23 17:00:40.884 debugLEVEL_STOP_ONOFF_COMMAND
dev:61172019-12-23 17:00:40.386 debugiterate: fadeUp 100
dev:61172019-12-23 17:00:40.205 debugSetting level to 100
dev:61172019-12-23 17:00:40.184 debugiterate: fadeUp 90
dev:61172019-12-23 17:00:40.008 debugSetting level to 90
dev:61172019-12-23 17:00:39.995 debugiterate: fadeUp 80
dev:61172019-12-23 17:00:39.819 debugLEVEL_MOVE_ONOFF_COMMAND
dev:61172019-12-23 17:00:39.011 debugiterate: stopped 80
dev:61172019-12-23 17:00:38.818 debugLEVEL_STOP_ONOFF_COMMAND
dev:61172019-12-23 17:00:38.800 debugSetting level to 80
dev:61172019-12-23 17:00:38.784 debugiterate: fadeUp 70
dev:61172019-12-23 17:00:38.598 debugSetting level to 70
dev:61172019-12-23 17:00:38.589 debugiterate: fadeUp 60
dev:61172019-12-23 17:00:38.338 debugSetting level to 60
dev:61172019-12-23 17:00:38.324 debugiterate: fadeUp 50
dev:61172019-12-23 17:00:38.135 debugLEVEL_MOVE_ONOFF_COMMAND
dev:61172019-12-23 17:00:37.019 infoSwitch On
dev:61172019-12-23 17:00:37.018 debugLEVEL_MOVE_LEVEL_ONOFF_COMMAND 

The battery is way off, but that always was.
Its up and down like a yo-yo. I replaced the battery and now showing at 50%

Current States

  • battery : 50.0
  • level : 100
  • switch : on
1 Like

Update: I added a setting so that you can toggle a puck between dimmer and switch behavior. Turn off the "allow dimming" setting, and it will behave as a simple switch.

2 Likes

That driver looks neat! I'll have to try it out. Since you mentioned:

...this actually sounds like the perfect case for implementing it as a button device, where the user could then map the start of a turn to startLevelChange() and stopping to stopLevelChange() for devices that support this. (Or maybe held for the start of a "dimming" turn and released for the stop, and a regular pushed for a swift, "on/off" move, assuming these are all distinct? Then it would be usable with Advanced Button Controller...my imagination is going wild.)

I had mixed luck with this thing--it was so sensitive I couldn't tell what events I meant to make it do and which ones it was just doing because I happened to be typing on a keyboard vaguely near it. Thanks for your work! I'll give it another try now that someone has figured out more than I was ever able to.

1 Like

So, the tradfri dimmer is actually sending over a report about the speed that the dial is turning? What are the raw reports out of the device?

The Somfondsk remote does not do that. It simply reports when you begin turning the dial in one direction and then when you stop turning it. It doesn't matter how fast or slow you move the dimmer...as long as you keep moving it at the minimum speed it doesn't report the "stop" to the controller. But when it does, that is all that it reports to the controller.

Someone on ST used the difference between the start and stop to calculate the amount that the dimmer should change but I just used them as button pressed to use the native startChanging and stopChaning commands.

Could something similar be done with the Tradfri dimmer? Rather than use any report of "ramping" directly out of the device, simply use the beginning and ending of motion to trigger actions in HE. Might make the dimming a lot more intuitive. Just a thought.

No, it doesn't send anything about the speed. Just start and stop. In my code, I have two parameters that affect the "feel" of the dimming. One is the step size (in % of full brightness), and one is how many milliseconds in between steps. I have these set to something that felt good when used with my GE z-wave plus dimmers, but I will probably turn them into preferences, so that you can adjust them as you like.

Okay...so, I'm confused why turning the dial fast vs turning it slow would affect how the dimmer performs. It seems that shouldn't affect it at all.

For example, I can imagine an ideal situation where the driver does a 1% step every 20 milliseconds. It would fade from 1% to 100% very smoothly over 2 seconds. In the real world (or at least in my mesh network), that would saturate the network, and it ends up not working really well. I tested a bunch of variations and settled on slightly larger steps, slightly less often.

Fast vs. slow does not affect the dimming rate. HOWEVER, within the firmware of the puck device itself, it registers it as a different event type if you do a large/fast twist. Instead of sending the "start fade change" command, it sends a "turn on" or "turn off" command. This happens inside the puck.

Think of it this way. There is a very short list of possible events that the puck is sending to Hubitat:

  • Fade up motion has started
  • Fade down motion has started
  • Fade motions have stopped
  • Turn on motion has started
  • Turn off motion has started
  • Turn on/off motion has completed (I'm ignoring this event. Don't need it.)

OH! Ok. You can't also tap on the puck? See, the Symphondsk remote only does level with the dial part and then supports single, double and tripple taps for the power commands. I didn't realize that the dimmer puck did that with the power. That's just weird. Like it was said earlier....very Swedish. LOL

That's for clarifying....I was toying with the idea of picking one up as they're cheap on eBay at the moment. Think I'll avoid that now.

No taps though. Only twisting motions.

That's the part that I didn't realize. Again...just weird. Probably why they developed the new ones.