Alternative to Forward Actions?

Is there any alternative to forward actions for getting notified about NEEO state changes? I have several pieces that I automate at home and the limit to one endpoint for forward actions seems quite... limiting.

What about websockets? any plans to support that as an alternative to forward actions?

Reply
34replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Boris Pruessmann currently i only know that forward actions are supporting one end point only. If you are able to Programm a litle bit and your automation is capable of reading other inputs then you can make very funny things if you know the right endpoints in neeo ;-)

    Only other solution is to build a SDK Driver that forward events, but i don't know if this can bring everything out.

    Reply Like
    • Markus , I was rather looking for an out of the box solution. Here's why:

      • I am currently writing an integration with Roon, so that I can finally replace my Harmony. The integration will allow Roon to turn on a specific recipe when I start playing music. I also allows me to turn of that recipe from within Roon. In addition, the music is supposed to stop playing when I end the recipe via remote.
      • I am also interested in a proper integration with Home Assistant. Of course, that requires a proper reflection of the current state so I need events.

      If I were to release both projects to the public, as story like "hey, you need to set up some other routing component to get everything up and running" sounds like a terribly complicated story ;)

      Reply Like
  • from a performance perspective you only want one endpoint and route actions from there. you are however able to add custom drivers and act on that as well.

    Reply Like
    • Niels de Klerk , what performance are you concerned about here? The NEEO performance? If you want to integrate NEEO with different other systems, I find the limit quite problematic (see above). It makes it really hard to just provide turn key solutions, potentially requiring different developers to coordinate.

      Now about the driver... there is a way to develop a driver that receives all system events? Can you point me to some documentation?

      Reply Like
    • 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.  

      Reply Like
    • Niels de Klerk , the example above doesn't describe end devices but other services that are part of the "home automation eco-system". Assuming that there is only ever going to be one other system that you need to integrate with seems quite limiting.

      I did have a look at some of your post and also spent some time writing my own NEEO driver about a year ago. I've also written custom components for Home Assistant to pick one HA product.

      Now, if you look at some of the integrations that you are mentioning, you'll notice that instead of forward actions, they rely on polling. Leaving out the fact that polling always introduces some additional latency between "action happening" and "changed noticed", I am having a hard time seeing that polling once a second by 3 or 4 different systems is more desirable from a performance perspective than pushing out the changes to interested services.

      Anyways, it seems that the thing that I am looking does not exist and there are only a few options:

      1. Rely of pulling instead of pushing changes. Introduces latency. Creates unnecessary load on the brain.
      2. Rely on forward actions. Limited to one endpoint, so I can only properly integrate with one home automation system.
      3. Do a combination of (1) & (2), with (1) being used for the system that requires less accuracy.
      4. Convert forward actions into websocket myself, making it much harder for others to reuse my work due to the complexity.
      5. Create a web-hook forwarder service that ideally would be compatible with the NEEO API. Seems pretty hard to achieve and still complicates set up for others.

      Do you think I've forgotten something, Niels de Klerk ? Or did I misunderstood you?

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

      Reply Like
    • Thanks,   Niels . I'll have a look at those.

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

        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

      Reply Like
    • 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.

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

      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.

      Reply Like
    • 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 😉

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

      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.

      Reply Like
    • 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.)

      Reply Like
    • 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.

      Reply Like
    • Niels de Klerk I thing you are making reasonable arguments that there are solutions that do not poll. From what I've seen, all of those solutions have in common that they expose their own devices. And of course you'll get the information pushed from the NEEO SDK - but only for that device.

      The scenario I am interested in doesn't really require and additional device - I want to be able to control an recipe, e.g. for an AV receiver. For that I also need the notifications because I want to stop audio output when I turn on the TV instead.

      In addition, I want some other system - let's say home assistant - to get notified when any recipe is activated because I want that to also control some light scenes.

      Reply Like
    • 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.

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

      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.

      Reply Like
    • 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.

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

      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.

      Reply Like
    • 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.

      Reply Like
    • 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.

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

      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.

      Reply Like
    • 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.

      Reply Like 1
    • 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)

      Reply Like
      • Fonzo
      • Fonzo
      • 2 mths ago
      • Reported - view

      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.

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

      Reply Like
    • 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.

      Reply Like
    • 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.

      Reply Like
    • 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.

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

      Reply Like
  • Boris Pruessmann

    As others have said, openHAB/homey do not poll at all.  The API has a way to subscribe to state changes and those state changes are sent to the endpoint via a post.  I found the forward actions limiting as well and when I wrote the openHAB integration - I included a repeater function to repeat the forward actions to one or more other endpoints.  This allows me to chain openHAB instances (my production and my develop version can then both get the events).

     

    websockets, while an interesting idea, is probably overkill for something like this.  At the heart of it, the only advantage would be to keep a connection alive (and all it's associated state).  There really isn't much of an advantage since there really is no session and really not any performance issues that would warrant a session.

    Reply Like
    • Tim Roberts Forwarding the events as part of some custom integration is not really the problem. I think it's trivial to implement and I have not doubts that I can get it to work easily. My concerns are more around the composability of different solution out there. If you look at the general HA eco-system, you'll find dozens of solutions that are competing or complementing each other. When I am investing my own time to write some code that I want to make publicly available, I'd much rather do that in a way that allows people to combine it with openHAB, homey, Home Assistant etc. If I were to rely on some additional components like e.g. a repeater I would make it much harder for people to mix and match.

      Websockets was an attempt to basically invert the direction of control. No need for NEEO to track all the endpoints to push to in the same way that it currently does. Just push the events to all open websocket connections. Of course, that is only beneficial if more than one websocket connection is supported ;)

      Having thought about that somewhat further, I think that support for MQTT could be a reasonable middle ground - rather constant resource requirements on the side of the brain but still an architecture that allows the integration of more than just one piece of code.

      Reply Like
    • 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)

      Reply Like
Like Follow