NEEO SDK 50.5 - Changes and Features
Dear NEEO SDK Users
Our SDK is currently evolving quite a bit, I am happy to announce that a public SDK release is coming up. For release 0.50.5, which is just around the corner, we have a huge bunch of new SDK features coming up. This new version of our SDK will not only allow you to start using lists and much more, it will also make it very simple to have multiple drivers running at the same time by initializing them automatically with a single command.
This does not only allow you to implement much more complex drivers, this also helps us to deliver integrations for more devices much faster.
To make sure your drivers can use the full potential of the new SDK features, we have to announce a few changes which are important to know:
NEEO SDK CLI
With the SDK release 0.50.x a new way of running the drivers through a `neeo-sdk` CLI will be available. The main target is to make starting of multiple drivers much easier. The new version makes the use of `startServer` deprecated, and there is no longer a need for the developer to manually call the `disoverOneBrain` function. To make sure your driver is compatible with the new CLI, check out the required changes in MIGRATION-0-50-0.md.
Switch - Boolean instead of String
To fix an inconsistency in the switch handling we changed it so that it now makes use of a boolean instead of a string data type. So if your driver does include a switch (addSwitch), you’ll have to change it accordingly. No need to wait for the public release of the SDK or the firmware, you can go ahead an do this change right now.
SDK Release Notes
- Now Supports "isLabelVisible" flag which allows to hide the label for textlabels when needed
- Added new bridgeDevice capability, for example a Philips Hue is a bridge device which can add multiple devices
- Added support for custom lists - Including example for a file browser
- Added new device type "MUSICPLAYER"
- Added "listbutton" and "listinfo" items to list builder
- The "addSwitch() setter" is now called with boolean value instead of string (BREAKING)
- The NEEO Brain version is now validated before starting the SDK instance (>= 0.50.0)
- Added support for automatic drivers start through the 'neeo-sdk' CLI
- Added new option to register a device
- Updated devicestate service, added registerStateUpdate function
- Added support for security code entry before the discovery
- Added more Sanity Checks
- Added support for recursive NPM installs on 'devices' directory
- Implemented subscribe/unsubscribe callbacks for devices lifecycle
To fix an inconsistency in the switch handling we changed it so that it now makes use of a boolean instead of a string data type.
Patrick Fiaux Patrick
Unless I am not reading the documentation carefully, the documentation does not seem to describe the data types at all.
I was hoping somebody can help me a bit to get me back in the right direction. I have been trying to get the new cli to work, but seem to have hit a roadblock. I have held off asking for a few days because I like to try and learn for myself, but at the moment I have run out of ideas. After multiple failures at getting the cli to work, I decided to try and build 2 drivers in the most basic sense. The goal was 2 drivers, 1 button from each driver, start using cli.
So I have one remote that always seems to run though it's power quickly and I may have figured out why the battery is being drained on it.
So this remote/brain combo is on the edge of my wifi network and I've got the NEEO link turned on for this remote - mainly because without it, I constantly get the 'connecting' message because it's really on the edge (probably should put an extender in that room - but that's another subject). With NEEO link on, I have very little issues with it (just a few pauses when I get too far from the brain).
I've always assumed the power draw was because it was probably reconnecting so much with my wifi (since it's on the edge) - however, I just noticed something else today..
The remote was sitting on a table all by itself (we weren't at the table) and every once in awhile - the screen would randomly turn on like something had nudged it. We were quite a distance away from it and I don't *think* that us moving around would have sent enough vibrations to it to trigger the screen to turn on.
Normally the remote is in the dock and I know this doesn't happen so I moved the remote around to different places (far away from us) and it would every once in awhile just light up.
1. Did something in the firmware change the sensitivity of the remote? Don't know
2. Could something hardware wise made the remote more sensitive? (this remote also has a very very small 'clunk' inside it when moving it side to side - like the battery is shifting a millimeter or so)
3. Is there a scenario where the screen will light up on a wifi reconnect? (which would happen randomly with this remote)
Either way - it's very curious..