We should also think about a smart way how we can indicate if an interface is in use or not.
We could drop not used ones from the folder, but maybe it makes more sense to set a switch within the file.
What do you think?
I think a switch would be the simplest solution. Something like:
exports.enabled = true;So if I got it right you want to give the API user the means to disable the developer mode but not to enable it?
We can call clearIO(āinterfaceNameā) within the hardwareInterface after all addIO()'s have been called. The clearIO function would then only process values that contain the indicated type.
I think we could create a data structure to which addio() writes the io points it just added. Cleario() could then use this data structure to compare against the io points restored from the file system.
Ok, now I am creating a bit of a confusion. I think I had an error in the thoughts from before.
I think the developer mode should be disabled by default and the API user has to set a variable to true for enabling it.
Good Idea
Agree
can you add a few lines of explanatory comments as you do the interface 
I will also help down the road to document the server and the editor code much much better.
Yes, thatās already on my TODO list. I will do that after I have implemented the few changes mentioned above. Probably will get it all done today or early next week.
Ok, I think Iām almost done. Still missing the comments though :-). I ran into one small issue. The webServer checks if globalVariables.developer is set before it can be changed by any hardwareInterface. If it isnāt set, the Web GUI doesnāt start. So I think that we should let the user either just set the developer and debug variables directly in server.js or we could create some kind of config file and load the values from there. In the API we would then just provide getters.
And I havenāt tested it all thoroughly yet. So if you find some bugs, let me knowā¦
EDIT: I have started to add some comments. I will add some more to the empty example and the philipsHue interface next week. Iām not really into this licensing stuff, so what shall I put on top of the files I created/modified? And you probably might want to cross read since Iām not a native speaker and might have produced some grammatical mistakes 
1 Like
I can have a look later at the webserver part so that it responds āin timeā.
The arduino hardwareInterface needs to have this functionality.
The server is put under the Mozilla open source license.
For the files that you have created you can write in to them:
Created by YourName on Date.
Copyright (c) 2015 YourName
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at Mozilla Public License, version 2.0.
For files that you have made changes to, you can add underneath the created line the following:
Modified by YourName on Date.
No worries,
As long as the idea is understandable, it should be fine.
Ok, I can see, how legacy programs using the arduino c++ libraries developer() function might depend on it. But nonetheless it would be more logical to set a global variable globally in some config file. I think to overcome this problem and maintain backwards compatibility in the arduino hardwareInterface when the developer command is received at
case 40:
if (parseInt(data, 10) === 1) {
globalVariables.developer = true;
}
else {
globalVariables.developer = false;
}
dataSwitch = 0;
break;
we could simply do nothing like:
case 40:
dataSwitch = 0;
break;
And remove the developer command from future versions of the arduino c++ library. In my opinion that would be a better solution.
I think itās a good idea to store the developer value in a config file.
It should be part of the object.json file where all objects are stored.
Itās a bit ugly programmed right now, because all objects have a developer value already and
I used the heartbeat loop to sync the object with the globalVariables.developer in the server.js line 458.
It is used to communicate to the Reality Editor if the developer mode for a particular object should be displayed.
This allows the user to move GUI elements around.
Maybe we can drop the global variable and continue with the object owned only.
This one is stored on disk (object.json) with any major change to the objects and loaded on program start.
Then the only question remains how does the developer web-GUI response as a whole?
There was a specific functionality I thought of, when adding the developer mode:
One should be able to build a project with only Arduino (or other external tools) and some web know how.
It was mend for If one wants to expose the project to others in some way and prevent that someone can temper around with the object. Its relevant since every Reality Editor has a developer mode switch. For simplicity reasons, it is meaningful that the arduino developer can stop the object within the Arduino code from exposing the developer services.
If one will have a ready to go object and that person only just learned Arduino, this would be the only way with his know how level to access this control. If we have it somewhere in the server, it creates a big entry barrier.
How about:
case 40:
if (parseInt(data, 10) === 1) {
developerOn();
}
else {
developerOff();
}
dataSwitch = 0;
break;Ah OK now I get it. I somehow overlooked the objectās developer flag. I thought there was only the global one 
So yes I agree with you we should drop the global flag for the objects and use the local ones instead. I think for the webinterface we should just introduce another global flag which the developer can set. Do you think we should let the developer set the global debug and the new webdeveloper flag directly in server.js or should we rather move that to a new config file?
I will implement it tomorrow I think.
EDIT
I now created the developerOn(objName) and developerOff(objName) functions which can turn on/off the developer mode for the specified HybridObject. Problem with the arduino hardware interface is that the objName is not passed on by the c++ librarieās developer() function but this information is vital if we want to enable the developer flag to be switched per HybridObject. So someone has to change that library and we will have to think of something if we want to be backwards compatible with the current library. Of course we would have to modify the yun Hardware interface to handle the additional input from the c++ library as well.
Temporary workaround for now is that the developer() calls are ignored in the yun hardware interface and objectExp.developer is set to true by default.
Additionally I replaced the global developer flag with a webdeveloper flag which can be used to enable/disable the web GUI.
And I will be able to test it somewhen next week. So no guarantees that it works
I think we are making things more complicated then they have been before!
I do not see any advantage of two separate developer modes and a flag for every individual object. It creates the potential for human error. Therefore we should go with the following solution improving the old model:
- The global and object specific developer mode is always false by default.
- Whenever developerOn() is called, the global developer flag as well all existing objects will be set to true.
- The add() function need to check back with the global developer flag in case developerOn() is called earlier.
- The web server is checking for the global developer flag every time the developer functions are being accessed. If global developer flag is still false, the server responds with a general overview of the object.
This way we make sure that an object is always started in a user mode and only intensionally set to developer mode.
Ok, makes sense to me. What is important with this model is, that we donāt have a developerOff() function, I think. Because if we had one, the behavior could become undeterministic. Imagine the developer calling developerOn() in one hardwareInterface and developerOff() in another. There is no way for the developer to determine which function is called first so it would be completely random if the developer functions are turned on or off in the end.
Points one to three should be easy to implement. I havenāt really looked into the web server code yet, so point four might take a while and we would have to determine what information to show. Maybe it would be better/faster if you implemented point four @valentin ?
Exactly, with this model we do not need developerOff().
I remember that I spend some time on point 4 before and that it was once implemented this way.
I will check if this is still the case and adjust if needed.
Ok, I implemented point 2 and 3. Didnāt set the global developer flag to false by default though. I will wait with that until point 4 is implemented.
As before I couldnāt really test it yet because I donāt have an iOS device at home. So I couldnāt check if all works as expected with the Reality Editor. I will be able to test it somewhen next week.
2 Likes
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