Change device type about node-red-contrib-amazon-echo

[datech]

John / @Barabba11 ,

I'm sure that you know, but this module is emulating Philips Hue bridge v1, which is a quite old device. It was released 2012, and soon it will be out of support. https://www.theverge.com/circuitbreaker/2020/3/6/21167813/philips-hue-bridge-hub-internet-connectivity-discontinued-cloud-updates

I hope that it will continue to work with Alexa after April 30.

Bridge v1 supports light devices, and currently, it is the only thing that I was able to emulate. I bought lately an old bridge v1 to try to reverse engineer the Hue API, but I don't want to invest any effort in this area until I know that it will continue to work after the end of April.

Thermostats are interesting to me too, but they are not supported even in Hue bridge v2. I not aware of the thermostat device, which is working without additional skill. The thermostat looks like a good candidate for cloud-based device.

Wemo Hub is supporting power sockets without a cloud, and they are also working with Alexa without additional skills. There are few node-red-contrib- modules that implement the Wemo API emulation, but still, it might be considered for future development.

For locks, motions and temperature sensors, and other device types, we will need a skill.

JohnB, thanks for your offer. I'm able to cover all expenses around this project for now. And I believe I will be able to do so even if it is cloud-based, but unfortunately, I don't have enough time for coding.

Thanks

[Barabba11]

That's strange it gave two separated commands at same time, are you sure you didn't make a mistake somewhere in your program?
Our hero found a way to simulate a Philips bulb.. and it seems there are no plenty of other devices to copy. As well as modules like this that works with 3rd generation, so let's be happy on what we have.
With this I can manage lights, fans, heat and blinds. We're waiting improvements for distinguish the commands and manage different Echos (assign different devices) with one hub only..

[CallMeAreks]

First things first:
No, it's not a mistake from my part. Neither is a problem with this tool per se. Since everything is exposed as "lights" when you say to Alexa to turn on or off the lights, without specifying the device exactly, it turns everything in that room (assuming you're using rooms). I can (and did) exclude the fan from the room group. But then I can no longer say "Alexa turn on the fan" without specifying which of my fans.

Second:

I am indeed very grateful for the work done here, but your second part serves absolutely no purpose other than trying to shut down a legitimate issue that COULD be fixed to make this node even better. To me: "be grateful for what our hero gave to us" is a pretty poor mindset.

[Barabba11]

My words because no other module support 3rd generation without skill. Hero.
My Alexa never changed the status of two different devices at one time, in the case I told a general name which can be associated to more devices it always asked me which one, without doing nothing before it was sure about a specific one. It's the first time I heard that, sorry

[And1DS]

Hi,
first of all thanks for this module, great stuff. It would be great to extend this to other device types, such as blinds, gates etc. Does anybody know what changes would be required to allow to control a gate by saying "Alexa open the front gate". I got it working already with the default on/off commands, but it feels silly to say: "Alexa switch on the gate" or "switch off the gate" even tho it works just fine!
Similarly I got the blinds working, here i can say "Alexa, set blinds livingroom to 90%" and it will almost fully close the blinds. Would be great to be able to say "Alexa open the livingroom blinds" and it sets it to 0% or 100% depending on how they are configured...

Any hint would be greatly appreciated.
cheers

Andreas

[zaphod2010]

have you ever checked out the alexa routines in the app? you can define custom voice commands and trigger actions.

[Barabba11]

this module is not able to extract the type of command gave to Alexa, it always pass the same parameters, so all the different messages produces the same object. Someone here found out the way to, sniffing the protocol he found that it is possible to know what type of message was told to Alexa. Unfortunately the author of module is not helping us to develope it more at this time.. I hope he will come back soon..

[thePhilipp]

the possibility to choose between lamp or switch would also be very interesting for me. In other Hue simulations that was possible. Is there already new information on this topic?

regards

[MattL0]

any news on this ? thanks :)

[jbreslin]

Any news on this development. I would make a huge difference if we could define thermostats or even sensors such as temperature or motion sensors etc.

I am happy to help if I can.

As a node-red-contrib this has a ton of potential!

good job, thanks

[datech]

Thermostats, motion, and temperature sensors could be supported only with Alexa skills. It means that we have to change this module to be cloud-related. In the current implementation, all devices are working locally, and there is no any nonlocal network communication initiated by the hub node.

I believe that if we switch to a cloud version, it will give us a bunch of new opportunities, except the fact that multiple different devices could be supported. In theory, the cloud version would provide us with an option to control the devices outside of your home. Maybe most of the people are using this module because it is local and easy to setup and going to the cloud might be considered as a security issue by them.

Do you think we have to rewrite the module to become cloud-related?

[jbreslin]

Hi Teodor,

I agree the main concern over many cloud services is the security risk but they can also be a pain to manage and are nearly always subject to "change at no notice" or service outages or withdrawal whenever the owner gets bored.

Local ownership is important so maybe two steps :

1. Allow definition of types that have parameters set like simple lights, dimmers, rgb, power sockets, TRV's, heating systems, televisions etc.

We can set parameters that are relevant to the device. If if the device provides unsolicited information like temperature etc that will not be available to the Alexa interface but would still be available to the local service in node-red and the node-red dashboard.

2. Look at a cloud based skill system that is optional for users who want to get real-time asynchronous messages. This could even consider an end-user private published skill. Maybe with google domain and an SSL cert this would be possible. I am happy to look at that.

I am happy to provide access to dedicated servers and static IP if it is any help. I am also happy to fund any associated costs of domain names and certs etc that can be held in any name you want. If I can help code then I will but I am limited in time...and ability! ;)

I have done some reading but clearly have more to do, the only good news is that I learn fast.

Node-red is great and I do all sorts with it but it is really brought to life by projects like yours. All your effort is really appreciated.

Cheers
JohnB

[Barabba11]

Thanks for your efforts, I think you should keep this as it is, local only working also when internet doesn't work. You may eventually add devices if they may be supported locally too (shutters for example).
Eventually you may develope another module that work with cloud, IMHO.
Thanks

[MattL0]

I won’t use the cloud portion of the module . I am only interested in local.

[Barabba11]

I don't think they will cut support to v1, there still people who are using it and I see no reasons to cut this service suddenly. There also is no problem to keep some more kB of code inside Echoes for v1 compatibility in future..
In case we'll argue with Amazon.
Thanks from heart fo all your efforts and work here!

[jbreslin]

Hi Gents,

This seems to split easily into two categories:

Actuators: We can control these using local functions only. They simply accept commands and may or may not acknowledge the command. It may be possible to add additional information in the acknowledgement but I will need to look into it further.

Sensors: Stuff that sends data asynchronously like temperature and humidity etc. These need some form of cloud based skill. There are options as to how these skills can be implemented and I will look at that further as a self-contained node-red skill (ssl and dynamic IP and publishing the skill presents some challenges!)

I am happy to look at just improving the actuators that can all be handled withlocal functionality first. Sensors can be handled in the node-red or other platform, so a cloud skill it is not so important for me just now and I suspect Barabba11 and MattL0 as well?

I like getting away from the single definition of the hue bridge as it restricts the parameters we can set and is not so clear what device is attached.

If an extended list of generic device attributes could created and then grouped to create generic device types is possible that would be great. As all device requires a commands in a specific format then we can use functions, templates etc to modify these for specific devices. This gives us manufacturer and device independence. I do this just now with frog-blue and Ikea Tradfri lights but I am limited as I cannot set the on-time for example.

I am happy to try do some of the work if you can point me in the right direction. I learn fast. ;)

John

[Barabba11]

I bleieve to have this module working locally without internet is an advantege, you can figure it out only when you internet may go out of service for days, for any reason. We need a reliable way to live in our home without interruptions or depending from something else.

By the way we need to add some other devices in the list, Alexa is improving vocal recognition algorithm and have all devices as "lights" can create problems, for example if I say "Alexa switch off everything" she's closing all my shutters, that's not a deal..
I hope we can have something like shutters and plugs (or fan) in next future, thanks a lot

[cdjm]

While dumping the configuration from my existing hue bridge I saw a field called archetype which is set for every device in the list. This node-red-module sets it to sultanbulb for every created device.

Perhaps it helps if we can make the device archetype selectable per-device to let Alexa recognize it correctly?

For example a tint powerstrip looks like this in the original bridge:

{ "lights": { "25": { "state": { "on": false, "alert": "select", "mode": "homeautomation", "reachable": true }, "swupdate": { "state": "notupdatable", "lastinstall": "2021-12-14T17:38:53" }, "type": "On/Off plug-in unit", "name": "Leiste 1", "modelid": "tint smart power strip", "manufacturername": "MLI", "productname": "On/Off plug", "capabilities": { "certified": false, "control": {}, "streaming": { "renderer": false, "proxy": false } }, "config": { "archetype": "plug", /* <- THIS ONE */ "function": "functional", "direction": "omnidirectional" }, "uniqueid": "REDACTED", "swversion": "MPLUG01" },
...