The current PhilipsHue implementation uses a config file to specify device id, IP address, etc.
The Pi’s GPIO implementation relies on a similar config file to define devices and assign I/O pins.
All HW interfaces support an enabled flag, which could be configurable.
I’m considering adding support in the nodejs UI for configuring that data, but want to make sure that I’m heading in the right direction and not duplicating effort.
Is this a good idea?
Is anyone else in the middle of doing similar?
If it’s worth it, I’ll throw together a quick prototype for review.
I think this is a wonderful idea. To allow a user to config aspects of a hardware interface in the web user interface is great.
But we need to think about a very strong simplicity aspect.
Right now the web interface is already a bit overloaded compared to 0.3.1.
How can we build it that it does not add more complexity to hardware interfaces that do not benefit from it?
I think special for the Hue light interface, that is a real big win.
But how can we prevent for example that a product designer working with Arduino is overwhelmed by all the options in the user interface?
Maybe the user interface changes based on which hardware interfaces are activated?
For example if only arduino is activated, then it will not show any extra options.
If hue is activated it would offer a hue setup.
We could add the html setup interface in the hardwareinterfaces folders.
If that setup sub folder is not existing, then there will be no setup button in the UI?
Yes!
Metaphorically, when we create interfaces, we should kind of aim for that in the very best case we would be able to explain it to a 9 year old kid.
If we can create a very low entry barriers, we can get more people on board.
From one side we can archive this with thinking carefully about the existence for every button.
For example I spend days on eliminating extra function calls in the Arduino IDE just to find the this very simple solution: "I am a developer(), I want to add() two IO-Points. I read() A and B and write() C and D.
I think that a simple web interface to configure a Hue Light interface is a big advantage.
It is very complicated for an average person to dive in to the server code and program a Hue interface.
On the other side, who is the person we build the developer functionality for?
I could also imagine that the biggest problem is the complex setup of the server.
What if you just open a webpage and you have everything at hand?
Is there a way how we could expose a javascript interface to program the hardware Interface code?
Kind of a Javascript IDE Arduino Style?
If there would be a Javascript IDE in the Web Interface that would allow to program an activated hardware interface that would be kind of cool.
I could even imagine that on some point we would just switch to firmata for the arduino and create a universal javascript interface for programming GPIO on what ever platform we have in mind?
This would allow us to share more generalized code.
If we control the GPIO from the PI via OnOff (and all other Linux Based boards), why not also control the GPIO from Arduino and so on via a node.js library as well?
basically like this
General GPIO API --> Webbased Javascript Developer Editor Code --> hardwareInterface API
We could then also use such a GPIO API to unify the HUE Light interface.
Additionally we could automate in such an editor what kind of hardware interfaces are enabled.
This would also allow us to just use Open Hybrid on the Intel Edison Board and similar devices.
Right now we have the Hue, Arduino, PI and soon Edison.
Every of these platforms needs a different kind of environment and different skills.
But in the end, all we do with these hardwares is:
switch on/off or PWM outputs
read digital or analog signals on an input.
More advanced:
maybe use some SPI or Serial communication for additional components
Servos and stuff.
A good starting point to think through this or even just use it is:
We can create an abstraction layer for all hardware in-between and let a developer program the logic via the Javascript Web IDE and simplified function wrappers.
With more research we might even find a project that already tries to build exactly the abstraction layer we can use.
As such, we could use the same code from the Arduino for the PI.
@KevinOrtman what do you think ? should we concentrate directly on this rather than build python adapter for the pi ?
This will allow the use of openhybrid on more platforms
There is another very simple programming tool that designers use and that is building up on javascript. http://processingjs.org
We could take inspiration from processingjs with some of our function calls for inputs and outputs and it would allow many many product and interaction designers in the world to program Hybrid Objects right in the browser.
@valentin So if we implement the ace code editor ,then it will allow the user to program the I/O of the hardware independent of which hardware it is ?
for example , the user programs the I/O from the java-script editor and then firmata controls the hardware ,is this what you meant ?
@V_Mohammed_Ibrahim Yes in some way.
What we have right now is a simple API to implement new hardwareInterfaces.
So to say we already have a simple hardware independent API to the VIRTUAL side of your Hybrid Object.
If we bring in another intermediate, so to say split the given API in a VIRTUAL and PHYSICAL API but more or less completely complementary, then we can use our hardwareInterfaces as another abstraction layer. It would allow a developer/designer to program platform independent code for what ever hardware and GPIO he wants to. Since we have the generalized API in Javascript, his code will work with any hardware interface. ± some small modifications.
This will make it highly simple for a unskilled programmer to build some javascript code for the hybrid objects.
This is the same thoughts for example Arduino used and which made it accessible for all the design schools. They abstracted a lot of c code in to a simple API.
What is relevant to me is that designers who have not much experience in programming are able to write programs for it. I can teach a simple blinking LED example with Arduino to someone that never programmed before, within a view hours. That is so powerful!
If we can generate something that has such a low entry barrier then we will enable product designers and beginners to playful experiment with the platform and eventually build physical designed objects. Objects that we could never imagine. Since we just provide a simplified API, a more advanced programmer should be able to leave this API aside and use node.js as it is.
If we have a configuration webpage, we allow a user to change a view predefined parameters, but we do not really invite to program their own creative ideas.
I do not see the open hybrid developer tools in the server as an end user interface.
Its purpose is to support the maker, designer and programmer to build hybrid objects.
A foundation for this building is code.
The end user should only power up a Hybrid Object and interact with it physically supported with the reality editor GUI.
I think it is a good idea to create such an abstraction layer because - as you said - it would reduce the barrier for new developers who wouldn’t have to bother with hardware specific details. I see the main advantage in the abstraction of the GPIO communications. But I think it might be quite complicated to abstract other hardware interfaces apart from the GPIO ones because I don’t think that we can simply assume that all operations will only be reading/writing numerical values.
Obviously your focus is the microcontroller/GPIO part but I think we will have to think about other applications as well (or only abstract GPIO). Otherwise we would artificially limit the possibilities. Just take the colour of a lamp for example it would be possible but quite awkward to represent it numerically. The need for more complex datatypes we cannot yet foresee will probably come up while new hardware interfaces and use cases are being developed.
@V_Mohammed_Ibrahim I named firmata more as an example for a hardware API then something we should use 1 by 1. I think it is interesting to look at what are all the functionality of firmata, like operating servos and so on.