@V_Mohammed_Ibrahim I think this work has to go hand in hand with the API optimizations Carsten is doing right now.
You can already see with his code that it is a lot easier to write a hardware adapter.
In the end you will have the choice to just write your GPIO interfaces right with the hardwareinterface API or if you want to build another bridge to something outside.

If you feel like python is the way to go and a common tool to program things on the PI, yes then maybe a python interface would be nice.

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. The other half deals with synchronizing between two “computers” (atmega and atheros) that have very different boot up timings. In python you might be able to just interface with the hardware interface API directly.
There are a lot of examples online on how to bridge between nodejs and python.

Maybe you should take a look at this: https://www.npmjs.com/package/pi-gpio 7
Seems to be very easy to address the gpio pins directly from javascript/nodejs with it

Your node.js version is probably to old.
Your log says v0.6.19 that is from 2012.
Try something >v0.10.28. The yun is currently running with v0.10.33.

Try to change serialport to “^2.0.5” in the package.json file.
With this change I could run npm install and the server with no errors on a mac with the latest node.js.
You might find more about node.js / socket.io and the PI online. Its an ARM system and might need different installations.

There is some good documentation for how to install nodejs serialport on the PI here:
https://www.npmjs.com/package/serialport 9

Other then this, if you have some time to wait. Carsten works a lot on improving the structure of the hardwareinterface. I think that you would benefit from waiting until that part is ready to be used.

Meanwhile if you really want to build the python bridge, try to experiment with some simple node.js example first. If you feel save with a good method, then it makes sense to work with the server code.

@V_Mohammed_Ibrahim You might find an interesting learning adventure to understand a bit more how to read these debug messages and then find a solution by your self.

For example you see in this message that something was not parsed rightfully in the node_modules folder.
The module is socket.io as you can see being the next subfolder.

The wrong parsing could be from the server code or from your installation.
Try out a small test project with socket.io and see if the error repeats.

If it does you have a broken installation.
If you google socket.io and raspberry PI then you might find some answers that could help you?
You can try to install socket.io globally:
npm install -g socket.io

If it does not, something in server.js is going wrong.
Maybe there is an issue with a version of socket.io?

It needs to be debugged. This is 90% of the work you need to do when you build something that was not there before. Start with small experiments first until you reached the point where you understand what is happening in the full picture. Try to break problems down in to their components until you have reached what is going wrong.

I want to encourage you to learn more on how to solve these error messages by your self.
You will learn a lot about how to debug node.js code.

I think some good first steps are:

1. Research online all methods on how to bridge/communicate between node.js and python.
2. With every researched option, make a small individual node.js experiment outside from the greater open hybrid server code. This is the best way for you to understand what is really needed and how it works.
3. By the time you are done with step 1 and 2 the new hardwareInterface API should be ready and with your new know how you will be able to implement the pyhton hardwareInterface.

What do you think?

I believe that this should not be a problem of the hardwareInterface but rather a problem in python. You will most likely find solutions for this problem in the PI/python communities.
For the hardwareInterface you basically want to extend the new hardwareInterface in to the python environment.

In python one should den be able to:

1. Add new IO points within a setup and go function.
2. Have some sort of listener or callback for when data from the IO points is coming in
3. Write data to the IO points
4. Allow to flip developer functions on and off.

Works like a charm. Thanks, @V_Mohammed_Ibrahim

Wonder if we should put those instructions in it’s own thread, or possibly the github README.md or wiki so it’s easier for other folks to find…

@KevinOrtman Thats a good Idea, I will add it to the open hybrid install guide on the webpage.
@V_Mohammed_Ibrahim is the guide above finished or should we add some more things before its added to the page?

I will also generate a drop down menu on the install page. By now we have a lot of guides.

Do you have some good sources for wiki systems that would allow use to rebuild the open hybrid webpage as a wiki? That would allow us to have more people involved in taking care of the webpage content.

We do not need images If it is all command line.
Maybe you can add what a user would need. Similar we did it with the other install guides.

Do you think it will work with the RASPBERRY PI ZERO as well?

The Pi install guide is online and I have structured the Install Menu items in to sub-menus:

Sorry for the delay in getting back with you. I wanted to make 100% sure that the steps were accurate.
So, I re-imaged my sd card to try from scratch (base OS only) and tried multiple variations on the install steps. The install/restore process takes quite a long time, thus the delay.

@V_Mohammed_Ibrahim I found that following the exact steps outlined above failed to install serialport. In my case, the default nodejs instance need to be uninstalled first, and the install via node-arm was a bit flakey. I had a better install experience simply uninstalling the default nodejs then installing v0.12 via nodesource (GitHub - nodesource/distributions: NodeSource Node.js Binary Distributions).

Here’s what I ended up with:

How to install on a Raspberry Pi

1. Use NOOBS 3 to install the base Raspian image.

2. Update the system software.

   sudo apt-get update
   sudo apt-get upgrade -y
   

3. Remove the default nodejs instance and replace it with v0.12 or higher (more details on nodesource github)

   sudo apt-get remove nodejs
   curl -sL https://deb.nodesource.com/setup_0.12 | sudo -E bash -
   sudo apt-get install -y nodejs
   

4. Get the latest OpenHybrid Object code and download dependencies

   git clone https://github.com/openhybrid/object.git
   cd object
   npm install
   

5. Run the OpenHybrid Object code

   node server.js
   

A this point, you should be able to navigate to port 8080 on your device and find the Object dashboard.

@KevinOrtman could you also your methods with the following branch?
https://github.com/openhybrid/object/tree/beta_hardwareInterfaces 4

It will become the master branch next week once we debugged it. A lot has changed.
It might be possible that the default nodejs version is working with this branch.

@Carsten worked on a new hardwareInterfaces that allows you to easily communicate with your hardware with nodejs.

Certainly.

The method works in that npm install completes successfully.
Server execution fails, however, with the following output. I’m in the process of debugging.

    pi@raspberrypi:~/object $ nodejs server.js
    got it started
    Loading template: base
    Starting System:
    Enter loadHybridObjects
    TempFolderName: null
    object Light1 has no marker yet
    TempFolderName: null
    object Light2 has no marker yet
    TempFolderName: null
    object test has no marker yet
    socket.io started
    Createing folder: /home/pi/object/objects/Light1/
    AddIO objectID: null   philipsHue
    Createing folder: /home/pi/object/objects/Light1/
    AddIO objectID: null   philipsHue
    it's all cleared
    Createing folder: /home/pi/object/objects/Light2/
    AddIO objectID: null   philipsHue
    Createing folder: /home/pi/object/objects/Light2/
    AddIO objectID: null   philipsHue
    it's all cleared
    found 1 internal server
    starting internal Server.
    webserver + socket.io is listening on port: 8080
    UDP listening on port: 52316
    base loaded !
    Loading template: documentation
    documentation loaded !
    Loading template: header
    header loaded !
    Loading template: home-object
    home-object loaded !
    Loading template: home-object-add
    home-object-add loaded !
    Loading template: interface
    interface loaded !
    Loading template: interface-rowitem
    interface-rowitem loaded !
    Loading template: monitor
    monitor loaded !
    Loading template: sidebar
    sidebar loaded !
    Loading template: target
    target loaded !
    events.js:85
        throw er; // Unhandled 'error' event
                ^
    Error: connect ECONNREFUSED
        at exports._errnoException (util.js:746:11)
        at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1012:19)

@V_Mohammed_Ibrahim do you get the same output when running the code in the beta branch on your Pi?

I should point out that master works without execption.

    pi@raspberrypi:~/object $ git checkout master
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.
    pi@raspberrypi:~/object $ nodejs server.js
    got it started
    Loading template: base
    object null has no marker yet
    object null has no marker yet
    object null has no marker yet
    socket.io started
    opneserial
    no problem
    found 2 internal server
    starting internal Server.
    webserver + socket.io is listening on port: 8080
    UDP listening on port: 52316
    Serial port error [Error: Cannot open /dev/ttyATH0]
    base loaded !
    Loading template: documentation
    documentation loaded !
    Loading template: header
    header loaded !
    Loading template: home-object
    home-object loaded !
    Loading template: home-object-add
    home-object-add loaded !
    Loading template: interface
    interface loaded !
    Loading template: interface-rowitem
    interface-rowitem loaded !
    Loading template: monitor
    monitor loaded !
    Loading template: sidebar
    sidebar loaded !
    Loading template: target
    target loaded !

@Carsten @valentin @V_Mohammed_Ibrahim

I was seeing that error because the philipsHue interface was enabled and trying to send an http request to a pH device. Should we set the exports.enabled flag to false by default?

I also ran across a few other minor items that could be improved while working through the code. I’ll submit a PR for your review.

Yes we should set the flag to false by default. The hue interface is very beta. It doesn’t have any error handling at all so far. At the moment it’s main purpose is to illustrate the use of the new API. I should have mentioned that in the comments.

Thanks for the confirmation, Carsten.
I did set the flag to false in my PR 1.

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!

Thanks for the help!
Peter

Hi @psomdecerff have you checked out what @Carsten did with the Hue Light interface?

https://github.com/openhybrid/object/tree/beta_hardwareInterfaces/hardwareInterfaces/philipsHue 6

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.

Mostly I’m learning a lot!
Thanks,
Peter

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!

I’ll think on this. My initial thought is that my opinion is of limited value because:

1. I’m new to RE
2. I’m new to JS and Python
3. 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:

1. Add error handling (check return state of http requests, check for the bridges return values,…)
2. write values to the HybridObject server only if the value has actually changed
3. Add a brightness I/O point
4. 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 1 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.

1. I think this will be quite straightforward for somebody who knows HTTP. Using curl the responses were easy to interpret, anyway.
2. 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.
3. Did this already.
4. 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.

Regards,
Peter

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).

Could you submit a Pull Request 1, or provide a unified diff 1 if that’s easier?

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.

Dumb Git questions below. I created a Git account, and made my own Git fork – psomdecerff/object – from the openHybrid project.

I think I successfully pointed my local clone to it.
pi@raspberrypi ~/beta/object $ git remote -v
origin https://github.com/openhybrid/object.git 1 (fetch)
origin https://github.com/openhybrid/object.git 1 (push)
upstream https://github.com/psomdecerff/object.git (fetch)
upstream https://github.com/psomdecerff/object.git (push)

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.

What detail am I missing somewhere?
Thanks!

I think I figured it out, using “phone a friend” option. Pull submitted for a handful of files with modest changes.

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.

Let’s see what others say…

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