CastleOS - new home automation software with Kinect voice control

[zenix]

All the how-to's are here: http://www.castleos.com/forum/forum1-howto-guides.aspx

 
For some reason Hue has no guide and Insteon is short on details!
 
http://www.castleos.com/forum/topic290-how-to-set-up-automation-protocols.aspx
 
 

Do you have a VPN installed or anything similar that affects the network? Including firewalls other than the Windows Firewall? Or is it still a clean Windows install other than getting all the Windows updates?

 
Clean Windows 7 install with default firewall settings (shows up green in the control panel).

 

[ChrisCicc]

The Hue guide is in the app itself under Hue settings, since it's just a quick two step process. That doesn't explain why it's not working for you, however. I can only presume the Hue bridge is not responding to the network discovery requests from the PC. Is there anything in your network that could be causing a problem? 

You can test with other Hue compatible Windows apps, so see if they are seeing the bridge as well. These two apps use the same Hue official API we use: 
http://apps.microsoft.com/windows/en-us/app/darklights/09fb8d8b-cefc-4215-b3b2-a87a483d6690
http://apps.microsoft.com/windows/en-us/app/huetro-for-hue/33553060-d57c-467d-8348-5e88071360c5
 
This app built their own unofficial API:
http://loginer.net/albedo/
 
If the first two apps see the bridge and CastleOS doesn't, we found a bug in CastleOS.

If the last app sees the bridge but the other two don't, we found a bug in the Philips sponsored API.

 

[wkearney99]

I have had mixed success with Hue on my network.  Since it uses UPNP and dynamic name lookups it's sometimes tricky to get things to 'settle down'.  I have my Hue bridge plugged into the switch ports of my R7000 router (configured as an access point).  Shortly after plugging in the Hue the router inexplicably did a factory reset, thus devices normally joined as part of the main subnet were suddenly behind a separate router.  Since the wifi devices controlling the Hue were also on the same subnet (behind the R7000) I didn't immediately notice the issue.  Not sure anything on the Hue is to blame but it was quite the coincidence...
 
I've noticed adding devices to the Hue bridge or pairing client software isn't always smooth.  Sometimes  it'll pair on the first try, others have taken three.  Again, no immediately obvious signs as to why.  
 
UPNP, Zeroconf (bonjour) , mDNS, WINS, etc, are all a crapshoot and a IO prefer to avoid them whenever possible.  There are UPNP and zeroconf browser tools out there, STFW for one that'll run on your OS of choice.  At least then you'll be able to see if your devices are actually squawking themselves to the network.

 

[zenix]

I can only presume the Hue bridge is not responding to the network discovery requests from the PC. Is there anything in your network that could be causing a problem?

 
Can't think what could be the problem. Hue is visible just fine from any iPhone and iPad, and can be discovered just fine from my iMac (using QuickHue app, both cloud discovery and SSDP discovery work fine).
 

You can test with other Hue compatible Windows apps, so see if they are seeing the bridge as well. These two apps use the same Hue official API we use: 
http://apps.microsoft.com/windows/en-us/app/darklights/09fb8d8b-cefc-4215-b3b2-a87a483d6690
http://apps.microsoft.com/windows/en-us/app/huetro-for-hue/33553060-d57c-467d-8348-5e88071360c5

 
"Get Windows 8.1 to run this app. Learn more" - these won't work on my Windows 7.
 

This app built their own unofficial API:
http://loginer.net/albedo/

 
This one worked. But I had to disable windows firewall - so now Windows is angry with me.
 

If the first two apps see the bridge and CastleOS doesn't, we found a bug in CastleOS.

If the last app sees the bridge but the other two don't, we found a bug in the Philips sponsored API.

 
Sorry, I can run only the last one, not the first two. Isn't there a log file somewhere which could bring some clarity to this situation?
 
 
Also, I think I already mentioned it, is seems like CastleOS's HTML interface is broken. There is no messages if login does not work, and similarly there is no updates on the "Searching for New Hue Devices..." page. It asks you to wait for several minutes, but it never completes. :wacko:

 

[ChrisCicc]

If you disable Windows firewall, does CastleOS connect to the bridge as well? 
 
For the interface, if the login doesn't work, it returns you to the login screen to try again. What message do you think we should add there to bring clarity to it?
 
For the Searching for New Hue Devices message, that's just informing you the search has begun asynchronously. You can continue using the app while it searches in the background. As new devices are discovered, they'll be visible on the Devices screen. 
 
Log files, if there are errors, are located in: C:\ProgramData\CastleOS\CastleOS Core Service\Errors.xml

If there's nothing there, I can send you an instrumented version to try out, but I'm guessing it's just going to show the bridge search begins but a bridge is never found :-/

 

[zenix]

If you disable Windows firewall, does CastleOS connect to the bridge as well? 

 
Nope, couldn't make it work with firewall off either.
 

For the interface, if the login doesn't work, it returns you to the login screen to try again. What message do you think we should add there to bring clarity to it?

 
Most sites spit out "invalid user name or password". It is good, if for no other purposes, just as an acknoledgement that the user entry, while not valid, was received by the web server.
 

For the Searching for New Hue Devices message, that's just informing you the search has begun asynchronously. You can continue using the app while it searches in the background. As new devices are discovered, they'll be visible on the Devices screen. 

 
Ok, I understand you now. It was completely not clear from the CasleOS UI though.
 

Log files, if there are errors, are located in: C:\ProgramData\CastleOS\CastleOS Core Service\Errors.xml

 
You had me confused for a few moments here. I had only "Program Files" and "Program Files x64" on the C:\. After some digging around I found a hidden folder "ProgramData", and - as luck would have it - an Error.xml within, with several thousand lines in there. 5357 lines to be exact. Looks like they are all similar and read like this:
 

<error timestamp="5/16/2015 5:05:04 PM">
<note></note>
<data>System.Collections.ListDictionaryInternal</data>
<message>An error occurred while sending the request.</message>
<innerException>System.Net.WebException: Unable to connect to the remote server ---&gt; System.Net.Sockets.SocketException: A socket operation was attempted to an unreachable host 192.168.0.167:80
at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket&amp; socket, IPAddress&amp; address, ConnectSocketState state, IAsyncResult asyncResult, Exception&amp; exception)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)</innerException>
<source>mscorlib</source>
<stackTrace> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Q42.HueApi.HueClient.&lt;GetLightsAsync&gt;d__12d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at p.e.h()</stackTrace>
<targetSite>Void ThrowForNonSuccess(System.Threading.Tasks.Task)</targetSite>
</error>

 
Do you know what that means? On a hunch I opened "192.168.0.167:80" in Firefox, and it brought up my "hue personal wireless lighting" web page. So this part seems to be working. Something else isn't. Any ideas?

 

[ChrisCicc]

So it appears it's finding the Hue bridge, but when it attempts to download the light list it's throwing the error that the Bridge is not responding. The error is occuring in the Hue driver, not CastleOS, so we got it narrowed down that far at least. 
 
Can you open the Hue app, go to About, and see what version is listed there?

 

[garyfunk]

Today yut mostly only know what the internet is via their tablets or phone;

What the heck is "yut?"

 

[RAL]

What the heck is "yut?"

 
See this thread

 

[garyfunk]

I got it. He means yute.

 

[pete_c]

Well then the use of yute, yut or yoot here...means the same to me these days...
 
I am though not dependent on my phone or tablet for any internet stuff.  My two year old grandson (infant yut) though is dependent on his Android tablet for Netflix movies these days much like a lot of yoot is today.
 
My wirelessly connected cell phones, tablets, netbooks and notebooks are typically in off mode (power off) when they are not being utilized.  Cell phone voice autoforwards to land lines here. 
 
Here I do not use or have UPNP, Zeroconf (Bonjour - Avahi)  and mDNS configured on PFSense; well never did.
 
The main wireless network / networks in their own subnets are autonmously connected via PFSense on different interfaces.
 
When testing (when I get around to it) the Amazon Echo it will be put on it's own connected wireless network not really part of the main home network.
 
I am also testing two wireless Wintel tabletop tablets which do OK the way they are configured. (lite/embedd Wintel XPe/7e Wintel 8.1 Lite.)
 
I do have some test automation devices (Securifi) configured in said manner (talking to Z-Wave, Zigbee and Hue and Cloud iOS/Android/Wintel stuff).
 
Looking at Chris's software only relating to Kinect stuff and have built a 19" 3M dual touch capacitance screen plus a tiny Atom Baytrail PC to it plus one of 4 Kinects purchased earlier in the year.  (doing similiar testing with Homeseer).

 

[zenix]

Can you open the Hue app, go to About, and see what version is listed there?

 
Hue app 1.8.2. It does not show new bridge firmware updates - says that bridge has the latest version.

 

[ChrisCicc]

Hue app 1.8.2. It does not show new bridge firmware updates - says that bridge has the latest version.

 
I've upload an instrumented version to the beta shared folder: https://drive.google.com/open?id=0B4ZX9h5IVCtnREk0TnZ2eldUWTQ&authuser=0
 
This should output to the Errors.xml file as it finds the hue bridge and devices. 
 
Thanks!!

 

[zenix]

This should output to the Errors.xml file as it finds the hue bridge and devices.

 
This one worked. I can see hue devices now.

 

[ChrisCicc]

This one worked. I can see hue devices now.

 
Great! But also interesting...I only instrumented Hue, otherwise it's the same code...
 
I threw a beta of the Kinect Service with Hue voice commands in the beta folder too... now you can change the color or white temp by voice like in the video..