PHBridgeResourcesCache

[IncorporateApps]

The PHBridgeResourcesCache class and the getScenes or getAllScenes return more scenes than on meethue.com or in the apps (Android or iOS) Some of those scenes are having only identifier names and are missing the normal names.

Is the getAllScenes method returning deleted scenes as well? Is there a way to return only available scenes that are visible on each app (android, iOS or Meethue ) with the correct names?

[SteveyO]

Apologies for the delay in getting back. Email notifications were disabled so didn't see this issue.

Scenes in meethue and/or the app are more like templates which are not initially stored in your bridge hence are often a source of confusion with the scenes in the bridge. Currently in the Android app all the scene settings are stored internally so these may not exist as scenes in your bridge. In the iOS app I believe the scenes are also stored in the bridge, so this would most likely explain why you see more scenes than in the apps.

The getAllScenes methods returns all scenes on your bridge so you should see the same results as the http command: http://{BRIDGE IP ADDRESS}/api/{USERNAME}/scenes

Currently this is no way to return scenes by app. A bridge scene has a Name Identifier and the corresponding light Ids. However, if you want to achieve this for your own app you could always store an identifier in the scene name and use this as a filter when retrieving the scenes.

Hope this helps.

[IncorporateApps]

Thank you Stevey for the reply

"Scenes in meethue and/or the app are more like templates which are not initially stored in your bridge hence are often a source of confusion with the scenes in the bridge."

Does this mean that when a user install an Android app and the Scenes they see that come with the app are not pushed to the bridge? So if a user never uses an iOS device the bridge will have 0 scenes? I believe the bridge comes with some predefined scenes, because when you first launch the meethue website without loading an app there are some scenes?

"Currently in the Android app all the scene settings are stored internally so these may not exist as scenes in your bridge. In the iOS app I believe the scenes are also stored in the bridge, so this would most likely explain why you see more scenes than in the apps."

Actually we have an iOS 5 device which has the old interface - the one that looks like the Android version, but it shows all scenes from the iOS7 device. The Android one shows less, but also shows iOS5 and iOS7 scenes. At the moment the Android device shows 30 scenes, the iOS devices 32, meethue shows 34.

"A bridge scene has a Name Identifier and the corresponding light Ids. However, if you want to achieve this for your own app you could always store an identifier"

The problem at the moment is that the bridge is throwing back scene names (real names) + identifier on some scenes and on others only identifier + some bogus identifier name for the scene (looks like the identifier - some random digits and letters). Could those be some deleted scenes from the apps - non of those scenes appear on any of the apps nor the website, or at least not with those bogus names - we did not go through each one to see which scene could have the same identifier - I understand identifiers are like Unique IDs in a Database?

It's a bit messy at the moment, you will have to agree...

[SteveyO]

To answer your questions:- "Does this mean that when a user install an Android app and the Scenes they see that come with the app are not pushed to the bridge? So if a user never uses an iOS device the bridge will have 0 scenes?" Yes, this is true.

"I believe the bridge comes with some predefined scenes, because when you first launch the meethue website without loading an app there are some scenes?" No, the predefined scenes are in the meethue website and the android app only, there are no predefined scenes in the bridge.

There could be deleted scenes from the apps. To complicate matters slightly in the iOS app when you create a schedule, it can create up to 4 scenes on the bridge (for On/Off and Fade In/Out) so maybe this is what you are seeing. The identifiers as I understand are Unique IDs, and are generated based on LightState properties/MD5 hashes. Not sure what the random letters on the scene name are (from the iOS app), I can find out but would imagine it won't help you much.

If you want to tell me your scene requirements I can ask some of my colleagues for advice on how you can proceed. btw. I fixed the bridge URL for getting scenes in my 1st post.

[IncorporateApps]

"There could be deleted scenes from the apps. To complicate matters slightly in the iOS app when you create a schedule, it can create up to 4 scenes on the bridge (for On/Off and Fade In/Out) so maybe this is what you are seeing. "

Maybe this is what it is - because if I have the same name of a couple of scenes (bluesky on 2 or more scenes) it shows as bluesky home or bluesky page 1 in the API whereas the website and the app only show the name (not sure why the API or the Bridge return the page on which the scene is to be seen inside the app are also shown)

As for the other identifiers, maybe the 4 scenes - different names- is the issue, but would the identifier be different on each of the 4 scenes? How would the app know that the 4 scenes are all part of one scene? Will try to track down what name on the app matches the random name returned from the bridge and API.

"If you want to tell me your scene requirements I can ask some of my colleagues for advice on how you can proceed. btw. I fixed the bridge URL for getting scenes in my 1st post."

Well basically, the idea is to have an app to control the scenes from the bridge (using notifiers for events) and the ideal situation would be to have all the scenes listed inside the app so that the user can use these predefined scenes from the apps, web etc. with his use cases (notifications)

[SteveyO]

As I understand, when the iOS app creates bridge scenes it generates an identifier and stores it internally in a database, so it uses this to map the app scene to the corresponding bridge scene.

If you check out your bridge scenes, using http://{BRIDGE IP ADDRESS}/api/{USERNAME}/scenes
hopefully this will become apparent.

To create an app to use the existing app scenes is a little tricky, the main problem is if you issue the above http command you will see the bridge only stores the scene name/identifier and lights in the scene. The actual light states are stored in the bulbs themselves.

The only way I can think of achieving your goal would be manually activate each scene, and once activated, capture the LightStates for the corresponding lights and store them internally (in your preferred storage format, eg. xml,json,db etc.). You could try and do this automatically by looping through each scene, although I suspect this would be harder due to the extra bridge scenes and working out the mapping between the bridge and app scenes.

[IncorporateApps]

Hello Stevey,

Thank you for the replies.

The scene issue is a bit of a mess, but we have another issue with the lights state - if we change the state via our app via the SDK there is no issue, but for some reason after some of the apps (iOS, 5, 7 and Android) change the state the SDK is not getting the actual last/actual stand of the lamps (for instance isOn is reporting the off state etc.)

If the state has been modified via the SDK via bridge.updateLightState then the app knows the correct state - and it doesn't matter if the app has been quit or if we manually reconnect to the bridge - the only state the SDK gets is the one sent via the updateLightState.

Not sure if this happened after the latest bridge update or not - using the latest beta Java SDK PhilipsHue-PhilipsHueSDK-Java-MultiPlatform-Android-v1.1.1beta-9-geef2e27.zip

Could you help out?

Edit: The same output can be seen on the Example App - PHUpdateLightStateActivity which Activity needs to be finished and restarted to update the state. We are trying to reconnect or recreate the object, but to no avail, only after we re-run the app can we get the last actual state.

Edit2: It seems that you can remedy the Example App by requering the AllLights in the read_cache command. If you use the first query for getAllLights onCreate it is not pulling the current state.

List lightss = bridge.getResourceCache().getAllLights(); PHLight light = lightss.get(pos);

But it does not seem to work on our test app for whatever reason...

[SteveyO]

Hi IncorporateApps,

It sounds like you are having issues with the BridgeResourceCache. In case you are not familiar with it I will briefly explain how it works. Basically when we connect to a bridge we start a heartbeat. This ticks every 10 seconds (ie. reads the full bridge config json) and on every heartbeat we update a BridgeResourceCache (inside the SDK), so every http get calls actually read from the cache and not the bridge, every PUT/POST updates the bridge and the cache so they are always in sync. The main reason for this is every get call can retrieve light states immediately without a bridge http call and can prevent flooding the bridge.

So going back to your issue, if you have 2 apps running, say the iOS and and your own (using the SDK), if you update a lightstate for example in the iOS app I would expect your own app to be updated within 10 seconds, depending when the last heartbeat was.

I have just tested the public QuickStart and Example apps and it appears the Hearbeat is running fine on these (if you have a http sniffer you can see a HTTP Get retrieving the full Json bridge config every 10 seconds) however, that's not to say there could still be a bug/issue somewhere.

A couple of things to check, when you say the SDK is not getting the last state of the lamps are you checking immediately? If so, then I would suggest waiting up to 10 seconds to see it gets synced. If you want to debug your code then you can break in the onBridgeConnected method (in PHHomeActivity), the phHueSDK.enableHeartbeat(....) line starts the heartbeat so a good starting point would be to see if this is started ok.. And if you have a http sniffer then great also to check if the heartbeat is running.

Let me know how things get on and will take it from there.

[IncorporateApps]

Hi,

Thank you for the reply.

Well, the Example App, when modified in the onOptionsItemSelected read_cache under PHUpdateLightStateActivity like this: List lightss = bridge.getResourceCache().getAllLights(); PHLight light = lightss.get(pos); (getting a fresh object of all lights) instead of using the lights List gotten via the onCreate will get the cache immediately on click of read cache, whereas our app will not. When switched back to the original code that uses lights.get(pos); then even after 10 seconds of waiting the read cache button does not get the current state.

But our app does not work even if we get the new resourcescache alllights in our cache read - even after waiting 10 seconds. We are using the same HomeActivity to connect to the bridge.

Oddly It works even after 1 second onResume when we switch the state via a background service via the SDK within the same app (a background receiver activity).

It is all very strange and we will have to find our way through the maze - do you have a more in depth documentation where things like these are explained in greater detail?

[IncorporateApps]

Its seems to be remedied by using the exact HomeActivity as in the Example app as opposed to the QuickStart HomeActivity , but the above scenario on the Example app is persistent - maybe you can test this?

[SteveyO]

Hi,

I have just checked the PHUpdateLightStateActivity.java (read_cache) and I see what you mean. This is a bug in the Example App code, the lights object is created in the onCreate method so the cache is only read once when the activity starts. This is clearly a mistake. I will fix this for the next version.

For now you can easily fix this by adding the below line: lights = bridge.getResourceCache().getAllLights(); just before you call the lights.get(pos);

I have tested this and it fixes. Thanks for the feedback on this, never noticed it before.

[SteveyO]

Regarding documentation we don't really have a more in depth explanation of the ResourceCache, the main source is: https://github.com/PhilipsHue/PhilipsHueSDK-Java-MultiPlatform-Android

In case you haven't done so already I would strongly suggest you check out the clip documentation, for light states it is here: http://developers.meethue.com/1_lightsapi.html

For example for debugging the above problem I checked the lightStates in the bridge directly using: http://{BRIDGE_ID}/api/{USERNAME}/lights/3

[IncorporateApps]

Yes, we have checked the lightStates - regarding the Sample App, the GetScenes Activity is also flawed, but we fixed it, maybe you can have a look there as well...

We will try and test it, is lowering the heartbeat contra productive/battery inefficient or can we lower it to 3-5 seconds without suffering any disadvantages?

On a slightly other note - our lights are humming when off (or when in on state with a "funny" light like very bright purple) - is this normal? We saw a thread on meethue with about 2 pages of reports that the apps are humming so it seems to be something that is not to be remedied soon and is known to the support at Hue, is this something that can be fixed with a hardware or a software update?

Here is the link http://www.everyhue.com/vanilla/discussion/515/hue-creates-high-pitch-noise-when-switched-off-/p1

[SteveyO]

Thanks again for the feedback. I have pushed the fix for PHUpdateLightStateActivity.java into Github. I will take a look at GetScenes Activity later. Lowering the heartbeat interval to 3-5 seconds should be safe but probably not much lower, especially if you are issuing many updates per second as you will increase the chances of flooding the bridge. Best to use your own discretion on this, we use 10 seconds as a safe happy medium.
To be honest never seen or heard of the humming issue. I will try and catch up with the hardware guys to see if they know about this. I will get back to you if I find anything of interest.

[SteveyO]

With regards to the humming issue I would recommend you call the customer helpdesk. The toll free number is 00800-74454775 for Europe or 001-800-555-0050 for the U.S. They would be more qualified to help you with this. Hope this helps.

[IncorporateApps]

Hi Stevey,

Thank you, but we already contacted support and nothing interesting is coming out of it so we were more interested in a more technical info on the issue - after all there are 2 pages of it on meethue alone and we have the same issue so it can't be isolated? Could you at least confirm that you are experiencing the same hissing high pitch sound on your bulbs or if not then also would be interesting which will indicate that there are bulbs that do not produce the high pitch sound and ours are faulty.

[SteveyO]

Hi, Sorry about this. To be honest I have never noticed it before. I have 3 bulbs at home and in the office probably around 40+ bulbs in my surrounding area and i have never noticed, and am particularly sensitive to high frequency noises. However, saying that am now in my early 40s which in theory means I can't hear higher pitch sounds so am obviously not the best benchmark.

Am back in the office next week so will ask some of my younger colleagues :-)

[IncorporateApps]

Hi Steve,

Thank you, the noise is audible in a quite environment, maybe you need to go up to it to hear it if there is more noise in the room.

We have yet another strange behaviour of the bridge - after a reboot of one of the routers, to test the autoconnect the SDK (and the Hue apps as well) are returning 2 bridges - the norma resides on .0.13 and the other one on .0.218 - both have almost identical mac addresses - one ends on 40:f1 the other on 31:60 (we have only one bridge connected - the one on .13) the one on 218 is also not returning the ping requests.

We will test what will happen when we disconnect the bridge, but it is strange?

[SteveyO]

For the noise issue I will hopefully have some more info on Monday, I have been given a contact person to talk to. For your other issue I need a few clarifications to understand the issue a bit better. I assume you have only 1 bridge (and never had a different one, or created a portal account with another one), is this correct? When you say you are returning 2 bridges, is this the result of a bridge search? Did you notice an IP address change after you rebooted, i.e. is the 0.218 the IP before reboot and 0.13 after? I have a few theories on what may have happened, will check on Monday and get back to you.

[IncorporateApps]

Never had another one to test in this environment, just 1

Result from search bothfrom sdk, sdk example apps and android hue app from philips.

We think it might have happened after reboot of router (more likely) or bridge, or both

[SteveyO]

Can you try this please. Do you see 2 bridges? http://www.meethue.com/api/nupnp The only explanation I can think of for returning 2 bridges with different macs, is somebody has created a portal account and they are on the same public IP as yourself (which of course won't be reachable, so that's why you couldn't ping it).

[IncorporateApps]

Yes, 2 bridges are returned.

Could you explain the second part in more detail? How can somebody create a second bridge or a portal account when there is only one bridge physically connected?

[SteveyO]

Thanks, that's good, at least the mystery is solved.

What I mean is somebody has most likely created a portal account on their bridge with their router, but as you share the same public IP a portal search on your app shows both. The portal stores its connected bridges using the IP Address as far as I can tell. This doesn't cause any problems as you won't be able to connect to the 2nd bridge, and selecting it from the drop-down list should return a Bridge not Connectable error (or similar).

You can always disable the portal search in your app (by using sm.search(true, false) ). This will only perform a upnp search however doing both is recommended for best results.

[IncorporateApps]

Hello Steve,

Here is the final product https://play.google.com/store/apps/details?id=com.incorporateapps.huenfc

Maybe you can add it to the Inspired or Apps we like setup? http://meethue.com/en-us/hue-inspired/

http://meethue.com/en-us/friends-of-hue/apps-we-like/

Thank you!

[SteveyO]

Great to see another hue app on the play store. Thanks for sharing the link.

I have passed on the link to the marketing team and they will look into it. They plan to add more apps to the Inspired/Apps-We-Like pages in the future but this may take a bit of time.

Good luck!

[IncorporateApps]

Thank you Steve,

Maybe you can test the app and give us some feedback at support [at] incorporateapps.com

We heard from one user that his LightStrip did not work with the app, but we never heard back on this.