<div dir="ltr">Hello folks,<div><br></div><div>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 we have developed a new approach to the arduino "bridge" interaction with CIAO :</div><div><br></div><div><a href="http://www.arduino.org/learning/tutorials/advanced-guides/ciao">http://www.arduino.org/learning/tutorials/advanced-guides/ciao</a></div><div><br></div><div>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 <b>ubus</b> 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 something similar that night at C-base in Berlin as first attempt of creating a sort of new approach to the bridge itself ?</div><div><br></div><div>This leads me to think about the possibility to use this solution in combination with <b>lininoIO</b>, 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.</div><div><br></div><div>Best Regards</div><div><br></div><div>Arturo</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-01 16:51 GMT+01:00 Felix Fietkau <span dir="ltr"><<a href="mailto:nbd@nbd.name" target="_blank">nbd@nbd.name</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-12-01 16:38, Daniel Golle wrote:<br>
> Hi Felix,<br>
><br>
> On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:<br>
>> On 2016-12-01 16:05, Daniel Golle wrote:<br>
</span><span class="">>> > I was following your posts and do believe there is quite some overlap.<br>
>> > It would thus be feasible to generalize the common parts (ubus call<br>
>> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared<br>
>> > interface the actual implementations shall use. In that way, people<br>
>> > can choose whether they want WebSockets, TR-069 or a suitable P2P<br>
>> > framework depending on their specific needs.<br>
>> > Has anything of your current approach at IOPSYS been made available<br>
>> > publicly (eg. on github?)<br>
>> ><br>
>> > From what I can tell there is also some overlap with Felix' proposed<br>
>> > System Configuration Abstraction Layer, just that my envisioned use<br>
>> > exceeds system configuration as it includes sensors, events and actors<br>
>> > rather than just access to a configuration model.<br>
>> If it makes sense, I'd be open to extending my abstraction layer to make<br>
>> it suitable for your use case as well.<br>
>> Feel free to propose changes to it if you like.<br>
><br>
> Having a first deeper look at scal I believe that access to sensors<br>
> and actors could be implemented inside scal similar to the existing<br>
> shell and system backends. That would be nice, as then scal would<br>
> make things available on ubus and provide the ACL mechanics.<br>
</span>Nice. Maybe we can reinterpret the acronym as "System Communication<br>
Abstraction Layer". I'd be fine with renaming it to something else as<br>
well, I just didn't find a better name for it yet.<br>
<br>
I think a good approach would be to add a dlopen plugin API to the json<br>
plugin itself, so you can use json files to parameterize access to<br>
sensors and other devices.<br>
<br>
Event handling could also be scripted through .json files using json_script.<br>
<span class=""><br>
> I'll have a deeper look and play with it to see whether that can<br>
> work.<br>
><br>
> Ideally, data collection (think: interface counters and such things<br>
> which need to be polled) and triggering events (think: link status<br>
> updates) should also be made accessible.<br>
><br>
> A local database which exceeds UCI state as suggested by Luka could<br>
> also be very useful, eg. for renewable energy or other applications<br>
> where loss of connectivity should never imply loss of collected data.<br>
</span>Makes sense.<br>
<div class="HOEnZb"><div class="h5"><br>
- Felix<br>
______________________________<wbr>_________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.<wbr>org</a><br>
<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/cgi-<wbr>bin/mailman/listinfo/openwrt-<wbr>devel</a><br>
</div></div></blockquote></div><br></div>