This thread is a good read, glad to see the H/W interface abstraction!
@Carsten, I’ll be experimenting with your fork, and I do have an iOS device so I’ll try to kick the tires on the developer setting mods you made, if I can get the Pi running.
1 Like
To get started on the pi you can just install it like @V_Mohammed_Ibrahim did. To get it working with the gpio pins fast you could take a look at https://www.npmjs.com/package/rpi-gpio or https://www.npmjs.com/package/pi-gpio. Looks like it could work out of the box. So you don’t really have to wait until the python bridge is finished because it seems you can address the gpio pins directly from nodejs/Javascript.
Let me know if you run into any issues with the hardware interface @KevinOrtman
Hi Carsten, I have merged your work on the hardwareInterface in to a beta_hardwareInterfaces branch.
I have some time on the weekend for debugging and adding the functionality we discussed with the point 4.
1 Like
Thanks, @Carsten the work you did on the hw interface is great! I’m waiting on some hardware to arrive (a GPIO breakout board for my Pi, and a brand new Yun).
Once I have that in hand, I’ll start tinkering with the I/O. I plan on using JS to interface, so I’ll base my stuff on the work that you and @valentin put into place for the Yun/Hue.
Thanks for the lib references as well. Looks like https://www.npmjs.com/package/onoff might also be a good choice - it had more monthly downloads than the other two combined & appears to support BeagleBone GPIO in addition to the Pi.
- Thoughts?
1 Like
@KevinOrtman While you guys do that i shall try to build an python- node interface using this https://www.npmjs.com/package/node-python
1 Like
Continuing the discussion from the Real Time monitoring error thread.
I created a new branch Bugfix_reinit where I moved the addIO() and clearIO() calls to the exports.init() function for each hardware interface. init() is now called the first time immediately before receive() is called. I tested it for all HW interfaces except arduinoYun and raspberryPi. Before we merge the branch into the beta_hardwareinterfaces branch it would be good to test those two as well. Maybe you could help with that @valentin and @V_Mohammed_Ibrahim ?
Testcase is as follows:
- Add some I/O points for the respective hardware interface.
- Go to the configuration dashboard.
- Add a target.
- Do not restart the server.
- Check that everything works as expected (Especially check that the I/O points are shown in the Reality Editor)
- If you want to do the test again delete the files from the objects folder
1 Like
Hello,
Start experiencing OpenHybrid, and the hardware interface. Sounds Good.
In particular looking at slider example: it seems little bit CPU expensive. So I’m looking for an improvement.
In fact I think, a pretty smart implementation would to send to /object/value, on each change on IO point (in writeIOtoServer).
So the continuous reading in Realty editor for changing values becomes not necessary.
Unfortunately, no access is possible for a socket.emit in writeIOtoServer.
What do you think of this suggestion ?
Other to do that ?
On which side do you see the CPU intensity?
The Server only reacts on events. This means for the time that there is no input change, the CPU should not be used very much.
You should write your code in such a way, that you only write to the server, if there is actually a data change.
From the Reality Editor side:
I can see that maybe a subscription model with pushed data would be working as well.
This can be up for discussion. However, the request model works for now and provides a simple interface for multiple devices.
What do you think?
Hi Valentin,
its a bit exaggerated for CPU activity: just for this slider exemple, we have when no activity on the phone, a request for info each 50 milliseconds.
Yes i think push model or event oriented sounds better at me, some eventEmitter could help around server.js .
For my understanding, the interface part (index.html and javascript files) run on the reality editor, i m right ?
I like very much your project.
Franck
Yes I think you have very good point.
It would be much less intensive if the Server would just push its data to the Editor.
But for that case, we would need to set subscription method for what kind of data should be send to the Editor.
Would you like contributing to it?
Yes that is right.
Its loaded as an iFrame in to the Editor and the iFrame is 3D-Transformed.
You can think about it basically as a regular webpage loaded in to a browser.
One thing to take care of:
The iFrame is created and the content is loaded in to it, once the object/marker becomes visible.
Once the object/marker is not visible anymore, the Editor waits for 3 seconds if it comes back and then removes the iFrame with the web content from the DOM.
This means that your CPU intensive webpage only pulls data for the amount of time the object is visible.
I agree. Maybe we could use the onload and onunload events. I’m not sure if and when they are triggered in an iFrame but it might be just what we need. If the events are triggered as expected - which should be tested first 
- we could put the subscription into onload and the unsubscription into the onunload part. In server.js we could then send the data to the reality editor whenever objectEngine() is called. What do you think?
@Carsten I think thats how it should be.
If its not working we can add the subscription to the library instance HybridObject() to be called one time.
I remember that the onload function can only be loaded one time. We would block it if a user decide to use it.
Maybe I am wrong.
If there is no onunload method, we could kill the subscription once socket.io declares the connection as broken/dead. Socket.io provides a couple of infos about the connection that are useful.
What I like a lot about this idea is, that we get rid of some extra timings in the javascript code exposed to a developer.
@valentin You are right. Instead of onload/onunload we should rather use the socket information. I’m not familiar with socket.io but isn’t it possible for the socket.io server to keep track of the connected clients? So the client could subscribe to the server when the connect event triggers and pass the information the server needs (objectID?) to send data to the client. When the server notices that the client has disconnected it just stops sending data.
Hi,
What is the primray branch to start development ?
- beta hardware new interface
- or Bugfix reinit.
Thx.
I will first try something: I will add winston framework for logging, a more configurable one. I hope you (@Carsten or @valentin, i don’t who is the integrarot in fact 
) will merge it.
@franck @valentin I would suggest that we create a new topic branch, branching from beta_hardwareInterface since the changes proposed have nothing to do with the purpose of the Bugfix_reinit branch.
@Carsten exactly.
socketUpdater() is doing such a check already.
We can simple check the bool <ourSocket>.io.connected.
However, the socketUpdater() is created to keep the sockets alive at any cost.
We would need to include special handling for GUI connections.
I am not quite sure, how to implement the subscription out of the box and I will not have much time to help this next two weeks as I am preparing/running a Hybrid Object design workshop.
Have you done something like that before?
If someone has to much time, we can also extend the socketUpdater() to check if an object has been missing for some time (this is the case, when socket.io connection can not be established for like a minute or so) and temporary deactivate links to that object. The deactivated links could be written in objectLinksDeactivated = {}. Once that link is available again, the links can be copied back. If the links can not be reestablished for 3 days, they should be killed entirely. This would solve a major GUI bug, which renders the GUI useless, if links to not reachable objects exist.
Ups… Yes new branch sounds good.
Ok, I created a branch: https://github.com/openhybrid/object/tree/eventBasedUI
@franck Please create your Pull Requests against this branch.
1 Like