[OpenWrt-Devel] [LEDE-DEV] [OpenWrt] Project proposal: The GNUnet of autonomous Things

[Daniel Golle]

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 <nbd at 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-devel at lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel