Add non Arduino I/O points

Hi everybody,

i’m just getting started with openhybrid. I’m wondering if it is possible to create I/O points which have nothing to do with the Yun. Let’s say I’ve installed openhybrid according to the guide http://openhybrid.org/install.html “How to make any Computer in to an AR Server for Web content” and have some objects like lamps which are read/writable via a REST interface. How can I create an I/O point which reads/writes such a value? Obviously you can create HTML interface elements which interact with those objects. But I would like to get “real” I/O points which can be connected to other I/O points with the reality editor.

Thank you
Carsten

The I/O points must be able to send the data to the server on pc ,
say if you have two independent programmable device (the function should be programmable) with WiFi connectivity and individual processors, then if the device is set up as each a hybrid object which can communicate to the server then it should be possible
while using the arduino yun ,it is the hybrid object ( i.e it can be considered as the bread toaster or oven as explained here
http://openhybrid.org/how-to-connect-everything.html )
you can also see the capacitive resistor with augmented resistance graph in the video
REST interface should be able to do it

@valentin this should work right ?

Hi Carsten,
Welcome to the forum!

You can program a special IO point in your hybrid object.
The object server runs with node.js and therefore it is possible to generate I/O points that can communicate with another REST interface.

This part is implemented but highly undocumented at this point.
You might want to look in to the folder “dataPointInterfaces” folder.

At this point only the “default” data point is actively used by the arduino library.
It works like this: Whenever the datapoint gets a new input, the function exports.render is called.
The call back (output) of that function will then trigger the server to process all connected links.

You can add other datapoints in that folder and they will be recognized at startup, but
I have not clearly implemented the use of multiple datapoint types in the arduino library.
Would you be able to help on that part?

@V_Mohammed_Ibrahim I think so.

Thank you both for your quick responses.

I started to look through the code and I’m wondering if what I’m trying to do is not better implemented as a new hardwareInterface rather than a dataPointInterface. As I understand it the hardwareInterfaces are supposed to handle data input and output from a certain source (such as the Arduino’s MCU). So in my case the data source would not be the mcu but some device adressable by REST calls. Isn’t the dataPointInterface just supposed to transform incoming data? As I understand it the dataPointInterface is not supposed to determine the source of communication.

@Carsten Yes, You are right. That makes more sense.

I will simplify the hardwareInterfaces over the next two weeks.
Because the code in the interface is to low level and to complicated. You need to study to much of the entire system to understand how to program for it. @V_Mohammed_Ibrahim you might have run in to this complexity when working on the raspberry PI interface.

I will merge the procedures in to the core files of the server so that hardwareinterfaces can build up on a simple API that only expose:

 clearIO ()
 addIO ()
 listenIO()
 writeIO ()
 developerIO ()
2 Likes

@valentin can I help you somehow? Do you already have a roadmap outlined?

@Carsten: To get started, you can study how the serial communication is used in

hardwareInterfaces/arduinoYun/index.js
line 109: switch (dataSwitch)

I can also comment a bit more in the code later tonight.
That would help probably to understand what is happening.
You could then help with writing the functions for the API or propose a better API structure if needed?

In the end the serial switch from line 109 would call many clean functions instead having this big blob of code.

What do you think?

1 Like

You can find some sort of long(er)term roadmap here:

We can open a separate discussion for roadmap points if you want to discuss them more.
We will also have a community meet up in the MIT Media Lab next March 3rd – 4th 2016.
That would also be a good space to discus a roadmap.

1 Like

Yes ! Doing that for the switch (line 109 ) would be better ,and i shall try to come up with some way to implement the pi interface,

OK I 've already looked at the code. It’s not too complicated, basically just parsing the serial input and adding/updating some values to the Hybridobject . I think I can help implementing the API. I will be back in office on Thursday and start to look into it then. Probably will’ve come up with some more questions by then :wink:

1 Like

Well, I’ve started to implement the addIO() function which is basically moving code from the switch construct to it. In the process I have come up with some questions:

  1. Why is the ObjectValue structure defined twice? Once in the
    yunHardwareInterface index.js and once in the server.js? Wouldn’t it
    be better to define it once only in the server.js and export it from
    there or move it to the HybridObjectsUtilities.js?
  2. I reckon you want to move all the functions to some core library part and export them from there? I think that will be possible for all functions except for writeIO() because as I see it writeIO() will have to know how to communicate with the underlying hardware and therefore can’t be as generic as the other functions. A way around this would be to define some interfaces to hide the specifics of each hardware which must be implemented by every hardwareInterface so that writeIO() can simply call those

P.S. Should we start a new discussion since this one has deviated from it’s original purpose?

@Carsten I moved the discussion over to New hardwareinterfaces API