I decided to focus on Pi <-> Hue comms before debugging my RE <-> Pi comms. I can load objects into my phone and see overlays, so I know I’m not too far away on the RE side.
It took me some time to get the Hue interface working, mostly because I’m barely competent, but it more or less works!
I learned enough curl to build Hue REST messages by hand. This was all new to me. Turns out the trickiest part is getting a valid username, and once I did that manually I just added that to the URL template so it’s still ugly, but functional. Getting IP address was pretty easy…lots of ways to do that, but from my phone app was easiest.
Took me awhile to figure out little things like the right ports. It’s 80 on mine, not 8000.
I added a level set to go with the state on/off. I re-learned vi a bit after a 20 year hiatus. Slow but steady progress…
Since I don’t have host comms working yet, I hacked in a level staircase that reads the level, adds a bit, writes the level, waits a while, and repeats. Sorta llike the generator loop I see in there to send to RE, only facing the lights instead.
It’s still a polling loop, reading the light state and trying to send it up to RE. I didn’t add change filtering yet.
It was cool for about 30 seconds. A light that ramps continually gets old pretty fast!
Yes, that is what I started with. I learned enough Git to get the Beta down, and turned on the Hue interface (and off the Pi interface, though I’m running on a Pi). I’m not sure if it all works for Carsten, but for me it did not, and it included only on/off while I wanted slider control of brightness too.
And it doesn’t include learning a Hue bridge IP or creating a username, though I suspect most people (probably Carsten too) figured out how to get around that. I think earlier bridges were more lenient than the later ones, but I’m not sure – I know mine errors without authentication.
Did some old-school debugging on the Pi, with console.log all over the place in server.js. and index.js. Fixed a few reference errors and stuff, took out a line or two in server.js that I couldn’t tell what did (may regret this later?) but errored, and worked around a logic issue or two.
I now have two PhilipsHue lights with separate targets for which I can control levels from my iPhone using a slider overlay!
It is rather slow, as I have yet to clean up logging much, but it works!
@valentin@KevinOrtman do you think it is necessary for a python adapter on will it be more easier for the user to program directly in nodejs if we provide a fairly easy and understandable documentation ? @psomdecerff what is your opinion on this ?
I’ll think on this. My initial thought is that my opinion is of limited value because:
I’m new to RE
I’m new to JS and Python
I’m new to Pi
I can say that even the “easy to use” Hybrid interface for the RE engine would be considered high-touch by most non-techies. Anything on Pi is pretty much the same. But, for those who say “it’s easy, it’s just standard Linux stuff”, I think either would work. Personally, now that I can kinda-sorta hack JS, it’ll keep me busy for a while. I believe data-flow diagrams with some pictures and arrows and some in-depth commenting would help.
I have further ambitions…I’ll see what I can butcher next!
Well, as I mentioned earlier, I created the hue interface mainly to test the new API I was developing. I didn’t really need it to do anything useful:
I think it’s quite impressive that you got it working for your needs @psomdecerff. I’m planning to make that interface usable, but it might take a while (with the holidays and everything). At the moment the hue interface can crash the whole system because I haven’t added any error handling yet. What I plan to do with it:
Add error handling (check return state of http requests, check for the bridges return values,…)
write values to the HybridObject server only if the value has actually changed
Add a brightness I/O point
Add a color I/O point
You are welcome to help implementing those points @psomdecerff and any other points I may have missed
Yeah, well, you will of course need a valid username and you need to know your bridges ip and port (I think all the bridges run on port 80 by default, I sometimes used this emulator which can run on any port). When you refer to “most users”, you are probably talking about you and me, I don’t think anyone else is using the hue interface at this point We should definetly write some sort of introduction which explains those facts and include some links to philips Hue resources like Get Started - Philips Hue Developer Program and Login - Philips Hue Developer Program
@Carsten,
I didn’t do much to address lack of error handling, but then I didn’t mind crashes while debugging. It seems to run quite reliably, and you already did all the heavy lifting. I just tweaked around the edges.
I think this will be quite straightforward for somebody who knows HTTP. Using curl the responses were easy to interpret, anyway.
Good idea. Right now it doesn’t seem to hurt much, so I’m not in a hurry to address this, but if I get more bulbs I probably will. I may get some more today.
Did this already.
My daughter thinks this would be cool. I’m not sure what the control should be, though. Not on this week’s list.
I am not yet comfortable with Git, and don’t want to screw stuff up. If you like to play merge master and look over my modest changes, I will happily send them to you. So far I’ve made changes in a handful of files (from memory):
config.json – updated URL and IP. Most of the pain here was learning how to add a username for my bridge.
index.html – Started off with a version that had a slider for LED, and changed it to level. At this point I don’t recall what I grafted from where, but really the changes were pretty modest. Could use an on-off button too, but it works with slider alone.
hardwareInterfacesSomethingorother - only added some debugging I think, to writeIoToServer.
index.js – spent a good bit of time debugging the bulb interface. Added writeSwitchLevel (which is not a great name, in retrospect).
server.js – a little bit of debugging in the RE notification handler.
Great work, @psomdecerff - it’s awesome that you got this up and running so quickly - warts and all!
I would be interested in seeing the tweaks you made (I’m sure @Carsten would as well).
It will take me a bit to figure out how, but yes. I’ll get a Git account and figure out how to do a fork, and start off with updating that. Right now my Pi is just a local clone.
I think I did a merge from upstream, and it didn’t complain. I also did a checkout, which shows several changed files; some I don’t recall changing but I may have while plinking early-on, and a couple of others I probably added a log to and then commented it out later.
pi@raspberrypi ~/beta/object $ git checkout
M hardwareInterfaces/philipsHue/config.json
M hardwareInterfaces/philipsHue/index.js
M hardwareInterfaces/raspberryPi/index.js
M libraries/HybridObjectsHardwareInterfaces.js
M libraries/templateModule.js
D objects/test/bird.png
D objects/test/index.html
D objects/test/object.js
M server.js
Your branch is ahead of ‘origin/beta_hardwareInterfaces’ by 7 commits.
(use “git push” to publish your local commits)
The issue I have is getting the changes to Push to my Github repository. It says it’s up to date when I just try “push” again, but I don’t see the changes online.
Sorry, @psomdecerff I just got home from work/dinner and checked this thread, so I missed your call for help. If you do have questions that need a timely answer, please don’t hesitate to ‘@’ name someone - I check email often, these forums less often.
That was a good pull request - great 1st PR ever! I see that Valentine has merged it, so I’ll grab the merged code and continue working with that.
No worries - I’m relatively patient and willing to dog through issues. I can’t imagine needing a rapid reply.
Thanks for merging it. Let me know if it doesn’t build for some reason. I think I included everything that I changed Do you want me to push an index.html for it too?
You mean like in the object/objects folder structure, right? I think that folder is more implementation specific and not typically distributed as part of the main project (?) that’s my impression anyways.
Hi @psomdecerff thanks for the commit. I added it to the project.
At some point it looked like you merged the master in to the beta branch. But the Master is very different from the beta branch in the moment. (I am sometimes confused about git my self.)
So I checkt through your code cleaned some of it up and compared it to the previous version of that branch.
There was one change in the server.js I was not quite sure about.
You commented an engine() call in line 1395. But that call is relevant to process links.
Was there some specific reason? Maybe a crash or something?
Something else we should maybe find a solution for,
I disabled all hardware interface by default, so that who ever wants to enable one should do that intentionally.
But I get error messages for onoff and the serialport (this is solved) on my mac.
What could we do, so that the packages are only loaded in case the hardware interface is really enabled?
@valentin, I probably did merge master – I’m sure I made several Git mistakes, hence my warning on looking closely at the pull.
The engine call threw an error I didn’t comprehend, yet the other internalModules call seemed to work fine. I haven’t played with links yet – is there a good example for those? I can uncomment and capture the crash, if that would help.
I agree that disabling all interfaces by default is a good idea. I kept having oddball objects laying around, and I accidentally re-used a target and confused myself even more.
You get an on-off error from my change? I’ll investigate tomorrow if I broke the beta.
@psomdecerff No problemo.
Your error could come from a strange mashup of code from the master that is different from the beta hardwareInterface.
I think the code is now all in sync with @KevinOrtman last commit.
Git is really a special kind of tool. I also still ask friends from time to time how to do certain things.
We are all learning
I don’t think you should use the existing HybridObject library.
It is optimized for the Atmega processor and its capabilities.
For example half of that library is dealing with minimizing the serial data communication by using lookuptables and dealing with string inputs matching to array indexes and all kinds of data allocations.
We should definetly write some sort of introduction which explains those facts and include some links to philips Hue resources like