Hey @simonkemper
It was really good to hear how excited you are about our dependent device support!
It is still very early days with just myself and a couple of other guys at resin.io playing with the feature, having said that I feel it is about ready for wider user testing to gather feedback and squash any bugs.
Everything we have done so far is open source and I have provided links to the repository’s and a draft of getting started guide.
Take a look and let me know what you think 
Hey @joe!
Thank you very much for sharing this information. To get a better understanding how things work, I guess it’s best to order some Microbits and start playing around with those.
But however I still have some questions here.
When reading about support for MCUs I thought that this would be a bit like what those guys at Particle.io are doing with their MCUs - They offer similar services (e.g. Firmware Update OTA, etc.) but all their services focus on using their cloud / third party cloud.
All in all they do not offer quite the same freedom you get from an embedded linux device and even if their hardware is available for a very low price - I still prefer using embedded linux SOMs / SBCs powered by resinOS / resin.io a lot!
So what is it like to use the dependent device support? Do those dependent devices (for example a Microbit) appear on the dashboard - just like other devices? And what happens when I push code into the repo / application? Will the code be pushed onto the dependent device / Microbit - or at least its firmware file?
So this means that there has to be a gateway which will program the MCU. But have you thought of different MCUs with WiFi / Ethernet functionality? What about having a “resin-bootloader” for compatible MCUs that will communicate with resin.io over Ethernet / WiFi, etc!?
I know that there once was a boot loader for Arduino which opened up an TFTP-Server when booting so that within the first five seconds one could push Firmware / Sketch onto it.
Well a resin-bootloader for MCUs like Arduinos (but maybe not those 8-bit units), that’ll be awesome 
I however let you know when I am working with the dependent device support and will give feedback!
Thanks,
Simon
Hey @simonkemper, very good questions, thanks for the detailed feedback!
Many of these are answered in the first link posted by @joe. For example dependent devices do show up in the dashboard (see the dependent_devices_dashboard/select_dependent_fleet_type.jpg screenshot), though not exactly as other devices, but as a special class.
When you git push a properly set-up repository with your dependent application code, and the firmware portion will be compiled and deployed onto the device (and taking advantage of the resin.io builders to compile the dependent device update file).
There will be a gateway indeed, but that gateway does not have to be a physical device, it just have to be able to connect to the devices. So one of the ideas we are working on is having the “gateway” online where all the network enabled dependent devices can connect to. It’s really just a dual-device model of “one that can run Docker and one that can be be connected to”, and there’s a lot of variations to this. Edge Node Manager for the Arduinos you mentioned could be also developed and I know that there’s some work done towards updating Arduinos over USB with such a gateway (just there were some unexpected blocks along the way).
Let us know if this helps and any feedback from your experiments!
Not wanting to hijack the thread here, but would I be far off the mark when I guess that the “dependent application” pattern will also be used for the highly-anticipated multi-container support on standard devices? 
Hey @cmoss,
I’m not sure if there’s a connection here between the dependent applications and multi containers.
I’ll try to gather more info though.
Hi @cmoss, a lot of internal discussion is going on regarding multicontainer support. That needs a lot more rethinking of the current patterns to make those work, but I can see how the similarities arise. For Edge Node Manager there might be custom development required by users to talk to their specific dependent devices, but multicontainer should be the same across the platform and handled by the standard tools most likely. Too early to talk about any specific implementation though. But yeah, working on it. 
Ok what comes into my mind when reading this is that we have a situation where we use a MCU as some kind of “Realtime Co-Processor” which is attached to the Resin-Board and that handles realtime or timing-critical task - mainly incorporated with I/O-Things …
In our concept we are having a dedicated container that handles communication with that MCU, Firmware-Updating, wrapping communication into a RESTful like interface
Another individual container is holding a redis instance and communication between those containers is done via redis - Yeah multi container 
love them!
Wow so funny since I had the same thing in my mind right after writing the post you replied to!
Haven’t had the chance yet to play around but I’ll let you know as soon as I have had the chance …
Hey @simonkemper,
I was on holiday last week - sorry for the late reply. If you have any more questions or stuff isn’t clear just let me know.
You can test with a micro:bit, nRF51822DK or an ESP8266 (support for this will be finished this week)
Cheers
hey @cmoss – nop, dependent applications and multi-container are not connected. The current multi-container work is pretty straightforward (push a compose.yml and resin builds multiple containers instead of one) but there’s a further multi-application step in our future. dependent applications are still not connected to that though
Ok, that’s a bit of a pity, I can imagine how a “dependent application” concept could really add to maintainability (i.e. pushing an update to just one of the multiple applications), or being able to establish a selection of applications, and “assigning” individual apps to a particular device, depending on desired configuration.
By the way, on a side note, the “official” blog on multi-containers: https://resin.io/blog/multi-container-with-docker-compose-on-resin-io/ would really benefit from an update. The approach is quite out of date now, and is generally pretty unstable once you get several containers with different persistence strategies.
The entire docker-wrapper used in that tutorial can be replaced simply by using the docker-in-docker image:
FROM docker:1.13-dind
I’d be happy to contribute an update, based on our experiences, however if you guys are pretty close to launching “official” multi-container support (which obviously I very much hope 
) it’s possibly not worth it…
Greetings @josephroberts,
I am looking to test out dependent devices but I am not seeing them anywhere in the resin.io dashboard. Is this still something that Resin is working on and can you point me in the right direction? Is this a paid only feature?.
I have done work with platformio and resin in a crude way and am actively pursuing this idea of using resin as an edge gateway for controllers.
UPDATE: found it.
I had to activate the RESIN_UI_ENABLE_DEPENDENT_APPLICATIONS=1 fleet variable.
Thanks,
Connor.
In our installations, we are planning on having a gateway (for our data) connected over wifi to a camera, which is further connected over Bluetooth to an ambient temperature sensor controlled by a nRF52832:
Internet <---> gateway (TBD OS) <--wifi--> camera (ResinOS) <--bluetooth--> thermometer
Given that the bluetooth connection may not extend from the thermometer to our gateway, this would mean that we would have to set the camera to be the “Dependent Device Gateway” and make sure that it has access to the internet. (and make sure that your nRF51822 firmware is modified to work with the nRF52832)
Did I get that right?