Hi Arturo, On Sat, Dec 03, 2016 at 03:58:17AM +0100, Arturo Rinaldi wrote: > Hello folks, > > as Kathy mentioned as first answer to Daniel, a proper setup running GNUnet > on our boards could give us a boost in the IoT world. During the last years
I'm pretty sure we are practically at this point already. Try opkg install gnunet-gns-flat (and maybe some more transports, such as gnunet-transport-wlan or gnunet-transport-http_client) Once you got that, you can easily use it to tunnel access to conventional TCP/IP services via GNUnet using gnunet-exit and gnunet-vpn, which are already well-integrated with the OpenWrt packaging I created to have GNUnet participate in BattleMesh during the past years. > we have developed a new approach to the arduino "bridge" interaction with > CIAO : > > http://www.arduino.org/learning/tutorials/advanced-guides/ciao Interesting and indeed similar to the lower layers of the GNUnet stack. I'll definitely have a deeper look at it. > > this is of course requires the use of Python as high level language since > it is designed around it but transparent to any kind of connectors. If I > understand well from this first email exchange, since *ubus* will be the > running engine of the new it is a completely native approach being it an > underlying running service of OpenWRT. Am I wrong or didn't John show Yes, and combined with Felix' SCAL project it will allow atomic ACLs and integrate with different middle-ware models. The exact machanics of remote access are *not* part of this unified stack, this is where freedom to use netconf, TR-069 or any other kind of remote management stack on top comes in -- I personally imagine something less centralized than current Web technologies as e.g. local machine to machine communication shouldn't ever depend on the availability of an external entitity of connectivity (ie. I still want to be able to locally control my heating system and have different systems of a smart home interact even in case of failing internet connectivity). This is why I see GNUnet in that place, because it comes with both, local area and wide area transports. > something similar that night at C-base in Berlin as first attempt of > creating a sort of new approach to the bridge itself ? I reckon this was related to Mediatek's LinkIT approach, but I do not remember the details. John? > > This leads me to think about the possibility to use this solution in > combination with *lininoIO*, our new approach for exposing the MCU gpio(s) > as filesystem devices and using them to interact with sensors, actuators > and so on (it was one of the topics of my talk in Berlin). Would this be a > reasonable approach for you ? Please let us know what you think about it > and in case we'll discuss it in the scheduled call. I imagine this to be a possible backend in the ubus/scal approach I'm envisioning. I'll have a deeper look at lininoIO so we can talk about that in more detail soon. Cheers Daniel > > Best Regards > > Arturo > > 2016-12-01 16:51 GMT+01:00 Felix Fietkau <n...@nbd.name>: > > > On 2016-12-01 16:38, Daniel Golle wrote: > > > Hi Felix, > > > > > > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote: > > >> On 2016-12-01 16:05, Daniel Golle wrote: > > >> > I was following your posts and do believe there is quite some overlap. > > >> > It would thus be feasible to generalize the common parts (ubus call > > >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a > > shared > > >> > interface the actual implementations shall use. In that way, people > > >> > can choose whether they want WebSockets, TR-069 or a suitable P2P > > >> > framework depending on their specific needs. > > >> > Has anything of your current approach at IOPSYS been made available > > >> > publicly (eg. on github?) > > >> > > > >> > From what I can tell there is also some overlap with Felix' proposed > > >> > System Configuration Abstraction Layer, just that my envisioned use > > >> > exceeds system configuration as it includes sensors, events and actors > > >> > rather than just access to a configuration model. > > >> If it makes sense, I'd be open to extending my abstraction layer to make > > >> it suitable for your use case as well. > > >> Feel free to propose changes to it if you like. > > > > > > Having a first deeper look at scal I believe that access to sensors > > > and actors could be implemented inside scal similar to the existing > > > shell and system backends. That would be nice, as then scal would > > > make things available on ubus and provide the ACL mechanics. > > Nice. Maybe we can reinterpret the acronym as "System Communication > > Abstraction Layer". I'd be fine with renaming it to something else as > > well, I just didn't find a better name for it yet. > > > > I think a good approach would be to add a dlopen plugin API to the json > > plugin itself, so you can use json files to parameterize access to > > sensors and other devices. > > > > Event handling could also be scripted through .json files using > > json_script. > > > > > I'll have a deeper look and play with it to see whether that can > > > work. > > > > > > Ideally, data collection (think: interface counters and such things > > > which need to be polled) and triggering events (think: link status > > > updates) should also be made accessible. > > > > > > A local database which exceeds UCI state as suggested by Luka could > > > also be very useful, eg. for renewable energy or other applications > > > where loss of connectivity should never imply loss of collected data. > > Makes sense. > > > > - Felix > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-de...@lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
