Alternative to Forward Actions?

Boris Pruessmann the forward brain events is meant to send all events to another home automation system that in it's turn can re-rout or directly control end nodes. The forward brain events are not meant for end devices. having the possibility to sent them to more than one system could indeed help in some cases. for turn key solutions, NEEO, the community or third parties can opt to build a SDK based driver. I have written multiple guides on how to use the API and SDK u can use. besides that there are a couple of integrations with HA products that all handle that for you.  

Boris Pruessmann the interpretation I’m referring to is the homey and OpenHab integrations. Both don’t poll.  I’m not aware of others.

  Boris Pruessmann Personally, there is no disadvantage in being able to send just to one endpoint. After all, one uses a home automation system of choice to control everything in the household. I know not many people who operate several home automation systems at the same time productive, so usually, this makes little sense, because the system what you use yourself should be able to control everything in the household.
If you want to control individual devices with feedback it remains only the possibility to write a driver or use an existing driver for the device. Otherwise, if you use forward actions, you must never pull because the status is always communicated to the external system. I myself used IP-Symcon and control everything that is available in the household via IPSymconNEEO

Fonzo Boris Pruessmann That's correct. with one addition. both homey and OpenHab provide a user interface where the user can "build" drivers themselves without coding needs by just defining a device, then add buttons or other capabilities and act on specific events of these. these solutions also support informing state changes back to neeo so the neeo represents the actual state of whatever you like. capabilities that can be used to represent a state are textfields, images, sliders and switches.

Theoretically any home automation system could do the same, it's just that it needs someone willing to put a lot of time into building something similar for their beloved HA solution. The NEEO SDK and API are certainly not limiting anyone as is i see it.

Niels de Klerk In the last point I personally have a different view. The NEEO SDK and the API are currently too limiting as it would be worthwhile to build a proper connection to an external system. In so far it is up to NEEO to finally add the promised features to the product with firmware updates.

Personally, at least I can not do anything remotely with a remote that can not even set colors, in which I am unable to adjust icons or the font size for example. And last but not least, the device has to support the features it was designed for and advertised so that a complete connection to third-party systems makes sense as Bluetooth functionality or the support of Zigbee.

Fonzo the color change of bulbs is (basically) in the current firmware, but due to its basic implementation, you need to add the slider as a shortcut manual. 

Yes it is no cool color picker or a nice picture, but you get a simple slider (or one for each color) if you add them.

Also I think the SDK and api that is available is highly satisfying (sometimes not documented) but available. It also can be used to send the ir-code of a button via a simple http call. Yes you need mostly search these this KS by hand and use the undocumented path but it is possible 😉

Markus Mahr  You could use rgb or a hsl slider, but that only shows what kind of tinkering is necessary to do a simple task, you can not expect from an end customer to use a RGB slider to set the color. Each app has a color picker to adjust color why not NEEO and the SDK? If you expect to sell this device also as NEEO Pro with the same existing sdk, you will not find a single integrator to sell this to a customer. Until there is no further improvement in the sdk NEEO don't have to think about entering the professional market, a customer wants full ability to design the interface of the NEEO remote for fonts and for icons.

Fonzo I don't be on the same line here.

A hotel as example only needs the ability to set a smart room with one or max two device. If the integration is based on the NEEO remote, then it can be made easy. Also currently there is no statement if the pro isn't customisable when it comes to the ui. 

Also neeo is working on a more user friendly way, the basic is allready available, I will not say that this is perfect or the most user friendly way, but it is there and can be used. Enhancements are allways possible, that's why software updates are made. (Yes the lag of frequent updates currently is also a not good solution.)

Fonzo a color component would be very welcome indeed. I’m sure it’s on their list and is sure to come. With every firmware update there is a new component and or new SDK/API feature. Good thing is that all components found in NEEO are exposed by their SDK.

Boris Pruessmann I have the same use case, and solved it by listening in to my AVR. as soon as the AVR is powered on the TV will be set to volume 0.

The NEEO SDK offers ACCESSOIRE devices these are ideal to di this using NEEO. Add a command named "TV volume 0" and one TV volume 10" for instance or just add a slider named volume. on the recopies you want the TV to be silent or not add the command to the recipe. you can also set a specific value to a slider in a recipe. so depending on your backend you could use a slider or buttons.

Niels de Klerk  Markus Mahr I do not want to talk badly about the existing sdk, with the sdk is more possible than with other remotes devices of this price class. I just want to say that personally I am very much waiting for improvements in some points. Whether hotel or not, I myself can change the color of Hue, Tradfri, etc. with every simply hue app. To sell a remote for controlling lights for over 400 euros which do not even do what every app for 1 euro can do is just not up to date.

I can not understand why I have to wait now for months for such a simple feature, what actually should be there from the beginning until finally a firmware update is published.

Fonzo the team behind the software needs time to program the feature. This time is limited. Soaybe they need the time for bigger issues you and me (and maybe all that are using the remote) don't see. Don't forget about the key, that they even build the bootloader and everything related in house. If you know have to build a color picker, you can do, but if your builded code then crashed the ir output (as example) you need to investigate why that happens. If you then found the issue it depends where corrections need to be made:

A) if you only need to change code in the color picker this can be done shortly without much impact and a fast fix can be implemented and spread.

B) you need to change the ir code driver for the Brain then you also need to check every source and target that is communicating with that code (low level change) that shouldn't be done on a short hand base and musst be planned and tested.

Don't know your background or if you know about all this or not, but maybe it helps you (or also other readers) to get a short info about a "small user change required" complaint.

Big other tech players have hundreds and hundreds of coders, checkers and alpha or beta testers. Neeo has only a handful of all of them, this also brings back a time delay for new features. If you don't test things you will earn complaints about it and users going to roast you and your product. That's not at all I like to see for a you'd startup company and had allready cost some good ideas the dead after short time.

Markus Mahr  I do not expect that the NEEO team programmed from scratch on a color picker, they can do that if they have the right people. But if you look under NEEO license you will notice that NEEO uses countless things which e.g. under MIT License. Why then reinvent the wheel when there are countless color pickers already there?
Take, for example, iro or similar that is completely alike. There is full documentation available. I'll give you right that you have to check everything but something like that can not take months to complete. Even any hobby programmer can do that within days or weeks at least for hue and tradfri.

As a startup, you can choose to either add features piece by piece or you can test so long and publish everything at the end together. But if there are no firmware updates for months, that does not really help for customer satisfaction.

Fonzo I fully agree with you, when it comes to Firmware Update cycle and already programmed things, but that's not the decision a customer can make. The company itself needs to guide itself in the right direction. They already perform adjustments and are now much more active here then it was in the beginning, but there is still air for enhancements.

When it comes to implement already coded things, there are two sides again:

a) everything is there but you need to checkup it and bend it to your needs

b) you rely on that code if something has issues it must be maintained (you own code or the external code)

Also these things must again fit in your programming and your code, this also needs time that may or may not be available due to other (heavier, zero-day, ...) issues that need attention.

But that's a endless way, we both agree that there needs to be some step forward. Also i think we are in line that the hardware itself is state of the art and nicely build. Also agree that software needs to be done.

But all in all we need to trust on that and only can wait to see something happen. I think something will change and i hope that it is not the Product become obsolete or outdated.

Fonzo the remote doesn’t use html. Like the app does. A lot of the remote is written in assembly as far as I know. So no shortcuts there.

Niels de Klerk Are you sure the remote doesn't use html?

http://<IP NEEO BRAIN>:3200/eui/#/home/rooms

is exactly the same interface in the remote as in the app. Why should neeo do the work twice?

this is not about hardware interfaces like z-wave or Bluetooth from the NEEEO brain. It's about a simple addition to the user interface and to control things like hue there is no need for magic because there is a documented API for HUE.

Fonzo they are doing a good job making it feel the same but yes im 100% sure. The level of performance vs power use wouldnt be possible with a html renderer. On all fronts They include new features with every firmware update. Some i don’t need but make others very happy and visa versa. We cant have it all at once. Im just happy to see new stuff and improvements with every version. I sometimrs see remarks about what Harmony can do, my biggest frustration with them was the lack of a proper API, there was so little improvement in regards to features. They are having their product way longer then NEEO with a much langer budget and team to work with. 

This doesnt mean i don’t have a huge wishlist for NEEO features, Some small and Some large. If they would do what i think is important the sure most others would be unhappy as my requirement differ to the comon user. Im seeing progression and for me thats a good indicator.

Fonzo 

I'm positive that it does not.  They have either some engine I've never heard of or have a custom built engine - but the input into is an XML file that describes the GUI (windows, dialogs, positioning, controls, etc).  I've even messed around with the XML file to create my own little GUI (the XML is not that difficult to understand)

Tim Roberts  Niels de Klerk ok if that is the case, then at least that explains why everything takes forever. From my personal point of view, it is not necessarily an advantage to have two different systems to maintain one for the app and one for the remote, as NEEO has to do the work twice. This also delays the simple addition of things if you have to feed them into two different systems. But if the design is like that, then you can not change it.

Fonzo true. From a dev point of view its not ideal. the gain is a responsive UI on the remote.

Fonzo Niels de Klerk Tim Roberts

I don't think they are using two different versions to display it in the app and on the remote. They just build there own Interpreter to display the XML in the "correct" way on either the remote or the app. But both are just wrapper, i previously mess around with the XML a bit to get a other Layout (displayed on an internal Webpage) and it was nice that it was working, but due to no requirements i moved away from it recently. But you are also able to build up your own Webpage / webapp to use a Customised Layout and interact with it (e.g. wall mounted Interface)

I love that this can be done without additional hardware and maybe use it someday, but currently i have no need. I also see a lot of forcome when a new software will be released, i also like the balance between new features and bugfixes they use with previous releases.

Hope they will continue with that and only change the speed of releasing it to public.

Markus Mahr The remote uses XML and has the components in the remote (within firmware). the App uses HTML and the brain provides the components to the app. Even the remote's background image is inside the remote and not provided by the brain. the two UI's are totally different.

Markus Mahr 

The remote uses XML, the app uses angularjs and are separate (that is why you get issues on one but not the other).  Now - I'm betting they have some source configuration files and an engine that will generate both (and that the errors introduced in one or the other deal with that generation) - but that's pure conjecture.

Tim Roberts Niels de Klerk then I only played with the XML that was generated for the remote 😊😉

Niels de Klerk is it impossible to target even a single end device? I’ve been waiting for 4 months now to get my HDFury vertex2 added to the NEEO database and was hoping I could control it over IP as it is already on the same LAN as my brain.

Boris Pruessmann 

I'd be fully on board with a MQTT approach but for a different reason - would allow me to create NEEO rules based on outside items (HAs, sensors, etc)