Probably just me, but do any others see various messages in the activity log which say…
“#### unreachable is 0” 3:38pm
"#### unreachable is 1" 3:38pm
"#### unreachable is 0" 3:38pm
"#### unreachable is 1" 3:38pm
Hi @Hilly_2015
I posted a separate thread for this as i didn’t realize at the time it was specific to this device type. @Sticks18 answered this for me here: [Device name] unreachable is 0? (Zigbee errors after platform update)
HTH
Thanks for that. Good to know that it’s nothing to be worried about - I’ll leave it be then. Just glad to have them working in the first place to tell you the truth!
If you grab the latest code, you shouldn’t see those anymore. I hid those messages since they’re not important and show up a lot as ST polls the device.
1 Like
@Sticks18 thanks for all the hard work on the device type.
I’ve got a strange problem with one of my five Lightify E27 bulbs…
Every day normally mid morning or early afternoon… it comes on… actually sometimes it flicks on and off a few times… only thing is… no commands being sent, no smartapps running (at that time) and nothing in the log …
2015-11-02 4:03:33.321 PM GMT
4 hours ago DEVICE hue 53 Corner Floor Lamp hue is 53
2015-11-02 4:03:33.292 PM GMT
4 hours ago APP_COMMAND setColor Lights At Sunset sent setColor command to Corner Floor Lamp
2015-11-02 8:28:28.692 AM GMT
12 hours ago DEVICE switch off Corner Floor Lamp switch is off
2015-11-02 6:56:24.043 AM GMT
14 hours ago APP_COMMAND setColor 2 Hours After Sunset sent setColor command to Corner Floor Lamp
2015-11-02 6:55:45.270 AM GMT
14 hours ago APP_COMMAND setColor 2 Hours After Sunset sent setColor command
So today it came on early afternoon…
Anyone else seeing this with these bulbs?
Might be a firmware issue or a dodgy bulb, but seeing as it seems to be totally fine at acting on commands when they come… not so sure.
Sounds like a bum bulb to me. It shouldn’t act without commands, which would show in logs. There were some ST poltergeists recently with the platform maintenance, so maybe it was just getting a very delayed command. Odd that it would only affect the one bulb though. Could be placement and interference or bad connection, but you did say it worked otherwise.
You might try resetting and re-pairing with ST to see if it just had a bad join to the network. If it continues, I’d get a replacement (store return or Osram) and try again.
Yeah that’s what I’m mostly thinking have unboxed for out of five 2 have worked perfectly 1 had this weird behaviour and 1 refuses to join, throwing errors irregularly… Even after the 5*3 seconds on and off. Guess I’ll get the last one joined tomorrow swap out this one and see if there is anything environmental causing the issue.
Anyone else have annoying buzzing noise from their lamps at full brightness with white light?
If I drop brightness to 50% or change color to anything but white it stops.
How are folks finding the connectable range on these?
I bought the 4 for 3 deal (and the Osram hub to update firmware) but am really disappointed that:
- I cant use them beyond about 20 feet.
- They dont seem to recognise or offer Zigbee repeating.
My use case is front door light that should turn on when someone arrives/door open/motion in the hall.
The door light is about 40 feet and one floor away from my Hub.
The Hub picks up my other zigbee devices over that range - the ST multi sensor on the door for example.
But it just wont operate the Osram over that distance. So I put two more Osrams as ‘hops’/repeaters between the hub and the furthest - they work fine, but dont help the furthest.
I also have an old ST motion sensor on USB power which should act as a repeater, near the Osram - no joy.
Ive mixed the bulbs around - always the furthest doesnt work.
If I put a WeMo bulb in, it works fine.
Im going to try using the WeMo bridge instead of ST to see if thats better.
Im aware other WiFi signals will interfere with Zigbee, but would have expected to see other problems if this was the cause.
They do offer repeating, there is much discussion about that in here: Osram/Sylvania Lightify (it works)
You probably need to rebuild the Zigbee network.
ST Motion Sensor is zwave right? It wont help with Zigbee network.
Have you connected them to the Osram hub and updated their firmware already though?
I bought 5 ES27 and 4 GU10 at the time of the offer.
Now have two bulbs outside and 3 running in the living room.
So far had 1 bulb not connect, one bulb with the auto on problem every day and never know which of the outside lights will be on or off when I get home… It is NOT a range issue as one is 5 foot from the hub the other is 10 foot from the hub.
However yesterday I found that one of the bulbs wouldn’t switch off even though toggling the device seemingly got responses in the IDE logs.
Hit the mains switch on and off in best IT Crowd fashion to reboot the bulb and … worked again… so at some level the bulb had crashed.
So I am hoping that when I get home tonight and link it temporarily to my new newly acquired lightify hub I can find a nice big juicy firmware upgrade waiting for me…
Zigbee. Whilst battery powered devices don’t repeat as it would use up too much battery life, The first generation ST motion sensor could work on either battery power or USB and is a zigbee repeater when on USB power. It was very popular for exactly that reason. I was sorry to see it discontinued. As zigbee pocket socket makes a good repeater for many cases as you get dual use out of it, but there has to be a receptacle to plug it into.
Yeah - updated firmware on the bulbs - it was particularly slow when compared to their GU10 bulbs (although they’re not colour, so might explain it).
I was getting the same results in the ST log - was saying command sent.
Just an FYI. The logs can be a bit misleading since the “events” that typically show up in the logs are part of the ST architecture and don’t necessarily mean the zigbee command was sent and/or received by the device. If you see activity in the live log that comes from a device’s parse() section, then you know that the device is talking with the Hub. Otherwise without doing some network traffic monitoring, it’s a crap shoot.
@Andy_Godber as Lake mentioned, it might be good to do a zigbee heal, which would be done by unplugging the hub for 15-20 minutes, so the zigbee devices can find their nearest neighbors. This might be part of the issue if you joined the Osram’s to your network from near the hub, then moved them away. They may still think they should be talking to the hub directly.
2 Likes
Don’t forget to take the batteries out if on v2 hub and doing a heal 
I am using four of these on rail and running the Circadian Daylight smartapp by @Kristopher. Osram RGB`s are connected directly to ST hub and show up as Philips Hue bulbs.
I have growing suspicion these bulbs are not getting/setting the colortemp correctly. For example now I´ve set the smartapp to sleep state where it should be in camp fire more with 2700K temperature, and by my estimation they are closer to 4000k. Its pretty easy to tell since I do have both 4000k lights and 2700k lights currently in same room.
I´ve added some logging into the smartapp:
debug colortemp2: 2700
a76b4bfd-774b-4980-b57f-a7450cb69195 18:15:13: debug Its after sunset
a76b4bfd-774b-4980-b57f-a7450cb69195 18:15:13: debug getCT currentTime: 1446912913071 , after sunrise: 1446876600000 , after sunset: 1446905220000
a76b4bfd-774b-4980-b57f-a7450cb69195 18:15:13: debug h: 0.27825367 s: 0.568952 b: 0.5
a76b4bfd-774b-4980-b57f-a7450cb69195 18:15:13: debug r: 255 g: 177.2002651415765 b: 109.91724515381793
a76b4bfd-774b-4980-b57f-a7450cb69195 18:15:13: debug colortemp7: 2700
So I know ST tries to set the bulbs to 2700k, but its not really working.
On device specific log I get the following (dont pay heed to the brightness changes, its something Í´ve done myself):
Date Source Type Name Value User Displayed Text
2015-11-07 6:15:13.114 PM EET
6 minutes ago DEVICE level 50 Kiskovalo1 level is 50
2015-11-07 6:15:13.080 PM EET
6 minutes ago APP_COMMAND setColor Kiskovalot sent setColor command to Kiskovalo1
2015-11-07 6:15:10.870 PM EET
6 minutes ago DEVICE level 10 Kiskovalo1 level is 10
2015-11-07 6:15:10.841 PM EET
6 minutes ago APP_COMMAND setColor Kiskovalot sent setColor command to Kiskovalo1
Kiskovalot sent setColor command to Kiskovalo1
2015-11-07 5:32:17.407 PM EET
I wonder if this is because the smartapp was originally written (I believe) for Philips Hue bulbs, not Osrams? Ie. are there different color ranges or whatever, which would cause the above commands not to function correctly? Is it a problem the setColor command shows no paramater in device log?
Hi Lake, if you’re using my devicetype (link in 1st post), then you should be able to select them under the color temperature section of the app, not the color section. That way there is no conversion from color temp to RGB values and you should get the exact color temp white light. You should see setColorTemperature being called instead of setColor in the logs.
Aha, thats the problem. I am using them as ST detected them without any custom device types. Thanks! And sorry im a noob
2 Likes
No problem. We all started there and it’s a shame that the first thing I do now when connecting a new device is check for a community devicetype with more functionality.
I’ll be submitting it to ST soon, but I might strip it down some first.
Don’t forget that custom device types won’t run local, but if you’re using circadian app, it won’t either.
1 Like
Hey @LakeEnd glad it worked out