Adding node server node returns HTTP error 400

Jimbo.Automates · February 12, 2018

I am trying to add a nodeserver node to Google Home in portal and it's returning an HTTP error 400. This used to work. I even tried deleting one that was already added, then re-adding it failed.

EDIT: To clarify, I currently have a nodeserver node in my GH list, so I know it used to work. @bmercier

Goose66 · February 12, 2018

+1 for this problem for Alexa as well. It is possible it has never worked since v3 Smart Home Skill and/or the Category selection option.

bmercier · February 14, 2018

On 12/02/2018 at 12:21 PM, Jimbo said:

I am trying to add a nodeserver node to Google Home in portal and it's returning an HTTP error 400. This used to work. I even tried deleting one that was already added, then re-adding it failed.

EDIT: To clarify, I currently have a nodeserver node in my GH list, so I know it used to work. @bmercier

Hi Jimbo,

Can you PM me the output of your node? I need to see what in the node may prevent it.

Use http://<your_isy_ip>/rest/nodes/<node_address>

Thanks,

Benoit

bmercier · February 15, 2018

Both Alexa and GH have been fixed.

Please try again!

Thanks,

Benoit

Jimbo.Automates · February 15, 2018

GH is fixed. Thank you!

Sent from my Pixel 2 XL using Tapatalk

Goose66 · February 15, 2018

Nodes from nodeservers now add in Alexa as well. Can't test voice functionality until Tuesday, but just about all of mine are currently in scenes or programs, so it would only be for testing purposes that I add one directly.

Goose66 · February 15, 2018

On a separate note, I would really like to see the TEMP_CONTROL nodes for my pool controller show up as thermostats to Alexa, so I could say things like "Alexa, what is the pool temperature" or "Alexa, set the spa temperature to 101 degrees" or "Alexa, turn on the pool heater." The TEMP_CONTROL nodes contain thermostat-type driver values, such as CLISPH and CLITEMP, but not every thermostat driver, e.g., mode (CLIMD ?) is missing but it does have an ST driver that controls the On or Off status (Off, Enabled, Active). What kind of nodedef.xml entries, device type settings, category assignment, etc. would we be looking at from a design standpoint that would make it apparent to the portal and the Alexa v3 Smart Home Skill that these TEMP_CONTROL nodes were thermostats?

bmercier · February 16, 2018

12 hours ago, Goose66 said:

On a separate note, I would really like to see the TEMP_CONTROL nodes for my pool controller show up as thermostats to Alexa, so I could say things like "Alexa, what is the pool temperature" or "Alexa, set the spa temperature to 101 degrees" or "Alexa, turn on the pool heater." The TEMP_CONTROL nodes contain thermostat-type driver values, such as CLISPH and CLITEMP, but not every thermostat driver, e.g., mode (CLIMD ?) is missing but it does have an ST driver that controls the On or Off status (Off, Enabled, Active). What kind of nodedef.xml entries, device type settings, category assignment, etc. would we be looking at from a design standpoint that would make it apparent to the portal and the Alexa v3 Smart Home Skill that these TEMP_CONTROL nodes were thermostats?

The node needs to look like an insteon or ZWave thermostat. Below is an example:

Important things are:

Type = 4.8.x.x (Or 5.x.x.x for insteon, but I would stay away from that)

The properties ST, CLIMD, CLISPC and CLISPH are mandatory.

UOMs for C or F are supported

Precision is supported.

ZWave example:

<name>Thermostat RC</name>

</devtype>

</node>

Benoit

Goose66 · February 20, 2018

On 2/15/2018 at 9:50 PM, bmercier said:

The node needs to look like an insteon or ZWave thermostat. Below is an example:

Important things are:

Type = 4.8.x.x (Or 5.x.x.x for insteon, but I would stay away from that)

The properties ST, CLIMD, CLISPC and CLISPH are mandatory.

UOMs for C or F are supported

Precision is supported.

ZWave example:...

Benoit

So there doesn't appear to be a way to get a nodeserver node to change its type. I have tried adding the attribute nodeType to the node definition, changing the NLS, and even adding a <type> node to the XML for the node in nodedefs.xml.

Is there any way the Portal could be updated so if a device is type 1.1.0.0 (appears to be the type for all nodeserver nodes) AND has the requisite ST, CLIMD, CLISPC and CLISPH drivers (properties), it could be recognized as a thermostat (or Thermostat would appear in the Alexa Category list) for purposes of adding the device to the v3 Smart Home Skill? This could be a temporary fix until some sort of nodeType attribute could be implemented in the nodeserver architecture.

xKing · February 21, 2018

nodeType was described in NodeServer SDK version 5.0.2 and then taken out in 5.0.4, I guess that decision needs to be reconsidered?

BTW, I use CLITEMP for current temperature in Nest, not ST. My understanding that ST means status of the device itself, not the status of it's surroundings?

Goose66 · February 21, 2018

I was using CLITEMP as well, but changed it to ST to accommodate Benoit's requirements above.

Chris Jahn · February 23, 2018

All Thermostats supported by Isy (Insteon/Z-Wave/Zigbee) use 'ST' as the current temperature, hence the requirement for using 'ST' for Thermostats supported by node servers.

Not sure of the quickest solution here. We have a "large" solution defined for all of this, but it won't be ready for some time. I think the simplest way to get around this for now is to allow the node servers to update the ISY Node Type directly.

Maybe something like the following would make sense, where we could maintain a public list of specific node types for node server nodes. It doesn't need to be a complete list at all because most devices can just be undefined, but for those we need to know, they could be added to the list.

e.g. Off the cuff possible node server node types of form <major>.<cat>.<subcat>.<level>

    1.1.0.0 - Undefined (default)
    2.x.x.x - Common Node Server Node Types
        2.1.1.0 - Thermostat
        2.1.2.0 - Temperature sensor
        ...
        2.2.1.0 - Dimmer Switch
        2.2.2.0 - Relay Switch
        ...

What do you think?

Goose66 · February 23, 2018

Perfect! Are you thinking it would be something we add in the nodedefs.xml and that would then drive output of the REST interface? I think the Mobilinc and Agave guys would be interested in this too.

Goose66 · February 24, 2018

Understanding that this approach would be temporary and that many devices would remain under the 1.1.0.0 "Undefined", I went through Mobilinc, the Alexa Smart Home Skill API (display categories and capabilities), the list of nodeservers for Polyglot, and the nodedefs.xml from Nodelink, and jotted down a quick list of Node Types that I though would be useful to Benoit and the Mobilinc/Agave guys:

2.1 – Climate Control
               2.1.1 – Thermostat
               2.1.2 – Temperature Sensor
               2.1.3 – Climate Sensor
               2.1.4 – Fan

2.2 – Lighting
               2.2.0 – Generic Lighting
               2.2.1 – Dimmable Light
               2.2.2 – Color Changing Light

2.3 – Appliance
               2.3.0 – Generic Appliance
               2.3.1 – Cooking Appliance
               2.3.2 – Scheduled Appliance (Roomba?)

2.4 – Barrier
2.4.1 – Garage Door
2.4.2 – Gate

2.5 – Security Alarm
               2.5.1 – Security Alarm Panel
               2.5.2 – Partition
               2.5.3 – Zone
               2.5.4 – Smoke/Fire/CO Alarm
               2.5.5 – Camera (?)

2.6 – Irrigation
2.6.1 – Irrigation Controller
2.6.2 – Irrigation Zone

2.7 – Door Lock

2.8 – Media Playback Device

2.9 – Group/Scene Controller

2.10 – Power Monitor

2.11 – Occupancy
2.11.1 – Motion Sensor
2.11.2 - Geofence

The list has little bearing on the ISY firmware or Admin Console, AFAIK, since they basically handle the display of all nodes in a consistent manner through their drivers (properties) and NLS entries. But it may be helpful in the Portal and for UI developers looking to make foray into 5.0 and nodeserver-supported devices, and hopefully won't be so different from the final solution that it will be hard to adjust.

xKing · February 24, 2018

For lights I would like to see:

Generic Light

Dimmable Light

Color Temperature Light (shades of white)

Color Changing Light

MultiZone Light (LED strips, tiles, etc)

Thanks!

James Peterson · April 13, 2018

On 2/24/2018 at 10:41 AM, Goose66 said:

Understanding that this approach would be temporary and that many devices would remain under the 1.1.0.0 "Undefined", I went through Mobilinc, the Alexa Smart Home Skill API (display categories and capabilities), the list of nodeservers for Polyglot, and the nodedefs.xml from Nodelink, and jotted down a quick list of Node Types that I though would be useful to Benoit and the Mobilinc/Agave guys:

2.1 – Climate Control
               2.1.1 – Thermostat
               2.1.2 – Temperature Sensor
               2.1.3 – Climate Sensor
               2.1.4 – Fan

2.2 – Lighting
               2.2.0 – Generic Lighting
               2.2.1 – Dimmable Light
               2.2.2 – Color Changing Light

2.3 – Appliance
               2.3.0 – Generic Appliance
               2.3.1 – Cooking Appliance
               2.3.2 – Scheduled Appliance (Roomba?)

2.4 – Barrier
               2.4.1 – Garage Door
               2.4.2 – Gate

2.5 – Security Alarm
               2.5.1 – Security Alarm Panel
               2.5.2 – Partition
               2.5.3 – Zone
               2.5.4 – Smoke/Fire/CO Alarm
               2.5.5 – Camera (?)

2.6 – Irrigation
               2.6.1 – Irrigation Controller
               2.6.2 – Irrigation Zone

2.7 – Door Lock

2.8 – Media Playback Device

2.9 – Group/Scene Controller

2.10 – Power Monitor

2.11 – Occupancy
               2.11.1 – Motion Sensor
               2.11.2 - Geofence

The list has little bearing on the ISY firmware or Admin Console, AFAIK, since they basically handle the display of all nodes in a consistent manner through their drivers (properties) and NLS entries. But it may be helpful in the Portal and for UI developers looking to make foray into 5.0 and nodeserver-supported devices, and hopefully won't be so different from the final solution that it will be hard to adjust.

This is exactly what I would need. If this was implemented support for NS would be easy. Without this, do not see it being possible to implement in a 3rd party app.

Jimbo.Automates · July 13, 2018

Now that the hints are available in 5.0.13A how would I categorize a node that does temperature and motion like the wireless tags? Probably should have made them separate nodes, but didn't want to since I wanted to group them under the hub.

Goose66 · July 13, 2018

So this may be a situation where the hint says, e.g., it is a motion detector, but it has driver values to support both. A front end developer would then display it with the motion detector interface of the front end GUI, but display the temperature driver value as an "extra" value. Later, if the front end developer decide she wants to support that node "natively," and implement a specific GUI for it, she could recognize it by the nodedef id attribute, perhaps. There's no point in making a list that includes every possible combination a developer could come up with. That's how you devolve into the nonsense that Michel was concerned about.

@Jimbo But I agree with you - to make the nodes most compatible with a generic front-end interface, like Alexa, you would want motion to be one sensor node and temperature to be another sensor node.

Jimbo.Automates · July 13, 2018

18 minutes ago, Goose66 said:

So this may be a situation where the hint says, e.g., it is a motion detector, but it has driver values to support both. A front end developer would then display it with the motion detector interface of the front end GUI, but display the temperature driver value as an "extra" value. Later, if the front end developer decide she wants to support that node "natively," and implement a specific GUI for it, she could recognize it by the nodedef id attribute, perhaps. There's no point in making a list that includes every possible combination a developer could come up with. That's how you devolve into the nonsense that Michel was concerned about.

@Jimbo But I agree with you - to make the nodes most compatible with a generic front-end interface, like Alexa, you would want motion to be one sensor node and temperature to be another sensor node.

Yes, I agree, and it gets more complicated because the motion sensor on these have different states where it detects door opening and closing based on the angle of the device.

xKing · July 13, 2018

Make it a bit MAP

128 bit integer, each bit would indicate a capability like for example:

0x0001 is a motion, 0x0010 is temperature

0x0011 has both

Michel Kohanim · July 15, 2018

@Jimbo

This is why we resisted this concept in general and types in particular. I think it's best to use nodes and attach the hints to specific nodes. Otherwise, we will be regurgitating the same nonsense as other protocols. And NEVER use bitmaps. It just defeats the purpose.

Hints should be used as hints and nothing else.

With kind regards,

Michel

xKing · July 15, 2018

Maybe add a specific "driver" name for Motion like we have CLITEMP and CLIHUM for temperature and Humidity?

Many things do detect "motion" from Nest Cameras and door bells to wireless tags.

Sign In

Adding node server node returns HTTP error 400

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Archived

Recently Browsing

Who's Online (See full list)

Forum Statistics