So they are not universal voltage bulbs like the Sonoff B1 bulbs.
No. Also checked out the Floalt panels. Same marking.
It could also be related to regional frequencies used for ZigBee.
I know that Z-Wave frequencies are different around the world. Unsure about ZigBee.
Thats a shame. Zigbee is universally 2.4GHz.
There is a change in the Tradfri Binding that was induced by @Kai (Kai Kreuzer) when modifying the original binding which I find very illogical. This is regarding the colot temperature. In the initial binding when sending “0” two the “color_temperature” challenge it would turn the light to the lowest color temperature i.e., the warmest light and “100” the highest temperature and coldest light. This I at least found very logical. In the current version this has been flipped around.
Could anyone explain why this was changed and how I could change this back to the original behaviour. I have tried with both the map and scale transformation on the item but I suspect that I’m not writing it correctly.
For my items, this is how they are normally specified and work:
Dimmer item_name "Name" <colorwheel> {channel="tradfri:0220:gwb072bfb31b8f:65537:color_temperature"}
And I have tried to change it to
Dimmer item_name "Name" <colorwheel> {channel=">[tradfri:0220:gwb072bfb31b8f:65537:color_temperature:MAP(tradfri.MAP)]"}
And I have a tradfri.MAP being:
0=100
1=99
2=98
3=97
...
This approach has been working well for my MQTT bindings but does not work at all for the trader binding.
Would be great to get som help on this.
Simple: All existing bindings for color bulbs (hue, LIFX, milight,…) do it the same way, so this is about consistency. The channel should maybe be regarded as a “warmth” channel - it takes a percentage between 0% and 100%, which defines how “warm” the light is.
1 Like
I just bought a Trådfri Color bulb (there aren’t shown on the IKEA Homepage yet). The Bulb shows up in PaperUI either as 0220 and 0100 Thing. Are there any plans to make them accessible?
When I change the color (white tones work fine) with the remote, there is thrown an error:
2017-09-05 12:18:10.596 [ERROR] [alifornium.core.network.CoapEndpoint] - Exception in protocol stage thread: Value must be between 0 and 100
java.lang.IllegalArgumentException: Value must be between 0 and 100
at org.eclipse.smarthome.core.library.types.PercentType.validateValue(PercentType.java:50) [98:org.eclipse.smarthome.core:0.9.0.201708151402]
at org.eclipse.smarthome.core.library.types.PercentType.<init>(PercentType.java:35) [98:org.eclipse.smarthome.core:0.9.0.201708151402]
at org.eclipse.smarthome.binding.tradfri.handler.TradfriLightHandler$LightData.getColorTemperature(TradfriLightHandler.java:329) [185:org.eclipse.smarthome.binding.tradfri:0.9.0.201708151402]
at org.eclipse.smarthome.binding.tradfri.handler.TradfriLightHandler.onUpdate(TradfriLightHandler.java:127) [185:org.eclipse.smarthome.binding.tradfri:0.9.0.201708151402]
at org.eclipse.smarthome.binding.tradfri.internal.TradfriCoapHandler.onLoad(TradfriCoapHandler.java:60) [185:org.eclipse.smarthome.binding.tradfri:0.9.0.201708151402]
at org.eclipse.californium.core.CoapClient$ObserveMessageObserverImpl.deliver(CoapClient.java:1067) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.CoapClient$MessageObserverImpl.succeeded(CoapClient.java:995) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.CoapClient$MessageObserverImpl.onResponse(CoapClient.java:974) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.coap.Request.setResponse(Request.java:509) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.EndpointManager$ClientMessageDeliverer.deliverResponse(EndpointManager.java:267) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.CoapStack$StackTopAdapter.receiveResponse(CoapStack.java:193) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.ObserveLayer.receiveResponse(ObserveLayer.java:137) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveResponse(BlockwiseLayer.java:321) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveResponse(ReliabilityLayer.java:269) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.stack.CoapStack.receiveResponse(CoapStack.java:135) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.receiveMessage(CoapEndpoint.java:656) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.access$700(CoapEndpoint.java:562) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl$1.run(CoapEndpoint.java:574) [175:californium-osgi:1.0.6]
at org.eclipse.californium.core.network.CoapEndpoint$5.run(CoapEndpoint.java:721) [175:californium-osgi:1.0.6]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
1 Like
I’ve recently purchased the tradfri smartbulb together with the remote and gateway. Even though the marking is 220V I’ve tried out in my house which is 110V. As for now, everything works great.
Interesting, the question now is whether a 110V marked bulb would work with 220V. Maybe the internal of these bulbs are the same.
I’m really looking for this solution. Do you have it in the github?
My openhab2 does not receive the status updates of a bulb made in the app or with a remote but when changing status in openhab2 it’s reflected in the app. Is this normal behaviour?
I also experienced this behaviour.
After a sudo systemctl restart openhab2.service it started working again. (uptime was 10+ days)
I now receive status from both the .brightness channel and the .temperature channel when adjusting from the Tradfri remote. I did not power cycle the HUB.
Yes now it’s working…thanks
1 Like
It is still not merged with master but you can play with the jars that you
can find here: https://github.com/S0urceror/tradfri-jars
It happened to me again. Seems like this happens after a few days. No events reported to Rules.
This is a less drastic way to get ut working again: (from Karaf console: ssh openhab@localhost -p 8101)
openhab> bundle:list | grep -i trad 13:29:11
180 │ Active │ 80 │ 0.9.0.201709011622 │ Tradfri Binding
openhab> bundle:restart 180 13:30:15bundle:restart "Tradfri Binding"
should work as well, That doesn’t fix anything, but it saves you some typing. You could even set a cron job to run something like this every night until it is resolved
sshpass -p habopen ssh -p 8101 openhab@localhost "bundle:restart 'Tradfri Binding'"
Curious user here: what is the observed stability of this binding in collab with the Tradfri system? Is it stable enough to use as a serious alternative to for instance hue or Z-wave? In other words: how is the WAF?
I’ve implemented some basic support for the color bulbs, but the conversion of the color is not very good at the moment.
4 Likes
3 Likes
Am I right, that this is not yet integrated in openHAB 2.2.0 Build #1043, or do I miss something?