NEEO - Driver Manager (ALPHA)

I ordered my NEEO yesterday and rather than clock watching I thought I'd try and be productive, so I started working on a NEEO Driver Manager.

After reading the forums it seems to me that there are some users who don't have any programming experience or are unfamiliar with JavaScript and Node. In addition, I personally didn't want to micro manage drivers and wanted a more "automated" system of finding/installing/maintaining them. So I started work on NEEO Driver Manager. I've added a link to an incredible lo-res (sorry!) video on YouTube of my progress after a few hours.

As I mentioned above I don't have my NEEO yet so I haven't test with real hardware and I also don't have any of the devices the drivers are trying to work with so some of them just error out when installed and started.

At a very high-level all this is doing is:

Searching npm for driver packages

npm installing the package you select

Using pm2 to manage the driver processes

In the short term I see this as a useful tool to manage drivers but I have a mini longer term roadmap in-mind:

Containerise/self-contain into a more user friendly installation (docker/exe/dmg etc)

Sandbox area for developing and publishing you own drivers (think stackblitz but nowhere near as good)

Install drivers via the NEEO remote (not sure if this will be possible, but I'd like to try)

Pie in the sky - build a Google Assistant app using Dialog flow and let this be the bridge between the NEEO locally and Google Home services.

The codes not up on GitHub yet as the GUI is awful but once I have that cleaned up and I have my NEEO devices to test on I will happily push the code up for everyone to contribute and report issues.

Hopefully this tool can make finding drivers easier and have better "advertising" around them as it makes it simpler for end users to use them. It might also help standardise naming conventions for drivers, e.g. neeo-driver-<x>.

We are working internally on making the driver development and re-use a lot easier. I'm sure there are some things we can consolidate together. Maybe it makes sense that you open a thread on the SDK's GitHub repository?

Thanks - it's still some way from being MVP and sharable with the community as outlined in the post above but it's getting there. I'll definitely create an issue on the SDK repo and share a link when its ready, hopefully the NEEO engineering team can pull the parts they like/want lol.

Niels de Klerk Thanks, I hope it turns out to be useful. I haven't been on here very long but I can see that you're very active in the community and are contributing lots towards the drivers and SDK development so I'd love to know how you get on with this and welcome any feedback you have :)

Chris Shepherd funny thing is that I’m not using any driver myself. Not having a driver manager plays a big role. I mainly use my homey integration because it’s easy to (re)start/stop code, have error log when something went wrong and automatically starts every code after a reboot.

it seems that you have most things already in place. So that’s really cool.

Something I’m not missing myself but think will help out the guys that are new to coding is if they can make use of a settings system. Thing is that most drivers that are made by users now include some static configuration like IP’s. making devices discoverable is for most users a step to complicated. Maybe a simple interface to edit for instance a settings.json could help making their drivers available to the “masses”. So this could be an idea as well.

Mike Potts So at the moment it is using a webpack development server which by default doesn't allow remote connections, however you can make one real quick change in the webpack,.config.js file. if you add:

host: '0.0.0.0',

in that config then it will be accessible via your debian vm IP+port. For example: http://192.168.12.50:3000 (assuming you debian vm ip is 192.168.12.50.

Its still beta so in the future I want it to be self contained and require no setup, but its not at that stage yet.

Mike Potts At the moment you have to manually add them by searching NPM, once installed the manager will auto start them. If they fail to run (nothing to do with the manager) then it will show as errored. So if you have some drivers already running it won't recognise them, you will need to stop the existing driver servers you already have running and then add them through the manager (providing the person that built them has published them to NPM).

It is limited at the moment but it is a start. After speaking with the SDK devs it looks like some useful driver management stuff is coming into the the next release of the SDK via a command line. When that is released I might be able to tap into it a bit more for things like discovery of drivers etc.

I would recommend pulling down my latest changes as it adds another fix in there for the websocket connection for real time GUI updates.

Niels de Klerk Thanks so much for trying it out and providing some feedback. Would it possible for you to raise these issues against the GitHub repo so I can keep track of them and take a look for you? Thanks again, much appreciated :)

Niels de Klerk So I spent an hour looking into the best way to distribute this as a production piece of software and after some playing around I think I am settled on an electron app (native wrapper around web based technologies). I put together a real simple example of it in the attached video. It will have the ability to auto start on boot which is a big win, but also some other nice features are opened up using the approach. I will have some time at the weekend to hopefully get this done and some more features complete too. Watch this space!