Adding node server node returns HTTP error 400

[Jimbo.Automates]

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

Edited February 13, 2018 by Jimbo

[Goose66]

+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]

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]

Both Alexa and GH have been fixed.

Please try again!

Thanks,

Benoit

[Jimbo.Automates]

GH is fixed. Thank you!

Sent from my Pixel 2 XL using Tapatalk

[Goose66]

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]

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]

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:

<node flag="128" nodeDefId="UZW0053">

<address>ZW011_1</address>

<name>Thermostat RC</name>

<family>4</family>

<type>4.8.6.0</type>

<enabled>true</enabled>

<deviceClass>1</deviceClass>

<wattage>1000</wattage>

<dcPeriod>60</dcPeriod>

<startDelay>0</startDelay>

<endDelay>0</endDelay>

<pnode>ZW011_1</pnode>

<sgid>1</sgid>

<devtype>

<gen>4.8.6</gen>

<mfg>139.21586.21561</mfg>

<cat>140</cat>

</devtype>

<property id="ST" value="234" formatted="23.4°C" uom="4" prec="1"/>

<property id="CLIMD" value="1" formatted="Heat" uom="67"/>

<property id="CLISPC" value="370" formatted="37.0°C" uom="4" prec="1"/>

<property id="CLISPH" value="230" formatted="23.0°C" uom="4" prec="1"/>

</node>

Benoit

[Goose66]

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.

Edited February 20, 2018 by Goose66

[xKing]

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]

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

[Chris Jahn]

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]

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]

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.

Edited February 24, 2018 by Goose66

[xKing]

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]

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]

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]

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.

Edited July 13, 2018 by Goose66

[Jimbo.Automates]

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]

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]

@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]

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.