Hello @johnstonf,

I have absolutely no clue! Editing posts is even more of NO NO NO for us than deleting spammer's posts. And, unfortunately I cannot find a log for activities. In any case, THANK YOU for all your support and I am so very sorry for the trouble. 

One question: are you certain no one else has access to your credentials?

With kind regard,
Michel

1 minute ago, Michel Kohanim said:

Hello @johnstonf,

I have absolutely no clue! Editing posts is even more of NO NO NO for us than deleting spammer's posts. And, unfortunately I cannot find a log for activities. In any case, THANK YOU for all your support and I am so very sorry for the trouble. 

One question: are you certain no one else has access to your credentials?

With kind regard,
Michel

Hi MIchel,

I'm sure no one has access to my credentials (or they'd probably wreak a lot more havoc than that).

Anyways, thanks for looking into it, and at least I know I wasn't doing something bad or wrong.
(for ONCE LOL...)

Fred

 

 

 

 

8 hours ago, drmacro said:

Well, deleting any/all ISY nodes does not make it go away and it still connects a web socket to the ISY944.

The node red console window last few lines shows AFTER the flow is deployed.

Note there are no ISY nodes, of any kind, in the flow.

 

I poked around in the "Manage palette" and noticed that there is a way to disable nodes. But, it says the isy-controller is in use and won't allow it to be disabled.

In the config tab of the dashboard sidebar, it shows the isy-controller on all flows and unused.

So, it appears, isy-controller is there even though I'm not using it.

Is this something I've done accidentally?

 

Try removing the node-red-contrib-isy module?

 

 

Interestingly, I removed the module after removing all nodes from my flow/s.

And it still was attempting to connect to the controller and throwing the error.

I found the an un-used controller node listed (it is apparently added magically by the install or the module...not sure) forced it to delete.

Then I restarted and no more attempt to create a websocket.

I currently have left the module out (while I tinker with GPIO input/control for other parts of this project), because it trying to re-connect every two seconds makes the debug tab unusable.

 

 

I wrote the node-red project pretty quickly and it’s definitely in more of a beta if not alpha state.  I wish I had some more time to devote to the project because I think it has a lot of potential.

@drmacro, what firmware version of ISY are you running?  That error indicates the xml being returned for variables from the ISY doesn’t have the expected elements (“val” in this case)..  Could you open up a web browser and send along the xml returned for the following url’s?

http://<<ISY IP address>>/rest/vars/get/1 and http://<<ISY IP address>>/rest/vars/get/2

If all else fails, you can suppress errors from any node in node-red by adding a “catch” node to the flow.

p.s. The controller node in node-red is what does all of the work, it gets created when the connection to the ISY is defined.  It’s called a “configuration node” in node-red.  A lot of nodes use them so that common configuration can be shared across nodes.  You can view all of them by going to “configuration nodes” in the node-red menu (the hamburger icon at the top right of the main screen).

1 hour ago, fahrer16 said:

I wrote the node-red project pretty quickly and it’s definitely in more of a beta if not alpha state.  I wish I had some more time to devote to the project because I think it has a lot of potential.

(I left an "issue" on your github, if you want contact me there, I might be able to help out some.)

1 hour ago, fahrer16 said:

@drmacro, what firmware version of ISY are you running?  That error indicates the xml being returned for variables from the ISY doesn’t have the expected elements (“val” in this case)..  Could you open up a web browser and send along the xml returned for the following url’s?

 

1 hour ago, fahrer16 said:

 

 

http://<<ISY IP address>>/rest/vars/get/1 and http://<<ISY IP address>>/rest/vars/get/2

Output of http://<<ISY IP address>>/rest/vars/get/1:

<vars>
  <var type="1" id="1">
    <init>0</init>
    <val>0</val>
    <ts>20180704 20:34:02</ts>
  </var>
  <var type="1" id="2">
    <init>0</init>
    <val>44</val>
    <ts>20180705 13:25:36</ts>
  </var>
  <var type="1" id="3">
    <init>0</init>
    <val>0</val>
    <ts>20180704 20:34:02</ts>
  </var>
  <var type="1" id="4">
    <init>0</init>
    <val>0</val>
    <ts>20180704 20:34:02</ts>
  </var>
  <var type="1" id="5">
    <init>0</init>
    <val>0</val>
    <ts>20180704 20:34:02</ts>
  </var>
  <var type="1" id="6">
    <init>0</init>
    <val>0</val>
    <ts>20180708 22:00:01</ts>
  </var>
  <var type="1" id="7">
    <init>0</init>
    <val>1</val>
    <ts>20180709 06:39:29</ts>
  </var>
  <var type="1" id="8">
    <init>0</init>
    <val>1</val>
    <ts>20180709 06:39:29</ts>
  </var>
</vars>

Output of http://<<ISY IP address>>/rest/vars/get/2:

<vars>
  <var type="2" id="1">
    <init>0</init>
    <val>0</val>
    <ts>20180709 06:39:29</ts>
  </var>
  <var type="2" id="2">
    <init>0</init>
    <val>0</val>
    <ts>20180704 20:34:02</ts>
  </var>
  <var type="2" id="3">
    <init>0</init>
    <val>0</val>
    <ts>20180704 20:34:02</ts>
  </var>
</vars>

 

1 hour ago, fahrer16 said:

If all else fails, you can suppress errors from any node in node-red by adding a “catch” node to the flow.

p.s. The controller node in node-red is what does all of the work, it gets created when the connection to the ISY is defined.  It’s called a “configuration node” in node-red.  A lot of nodes use them so that common configuration can be shared across nodes.  You can view all of them by going to “configuration nodes” in the node-red menu (the hamburger icon at the top right of the main screen).

Hmm...it might be my in experience with node-red, but I have no node to add a "catch" to. The configuration node is there, but I see no way to add a catch. It also gets into a mode where it sees the error described and then attempts to reconnect every two seconds. So if there is a place to put the catch, it still doesn't stop the network traffic with the reconnects.

@drmacro, thanks for the XML.  Based on the XML you provided, the variable definitions in your ISY don't have the "prec" element.  I don't recall when variable precision was added, feels like ages ago but I'm not sure where to check.  If you update your ISY to a recent firmware that error will go away.  I'm not sure if @Michel Kohanim would know which firmware revision introduced variable precision.

The ISY typically does a fantastic job maintaining backwards compatibility as things move forward but I suppose this brings up an issue that adding backwards compatibility earlier than the firmware this project was developed with would be very difficult.  If I can find some time, it might be a good idea for me to add a firmware version check to this project and prevent it from running if the firmware revision is unsupported.

Someone please correct me if I misunderstand the ISY firmware status.

I know there are versions later than 4.6.2, but, none are released. Being un-released, I would need to update by downloading and forcing an update.

 

Ok, so I upgraded the ISY to 5.0.13.

Same error.

?

Also, with 5.0.13 it appears to be rejecting or having a problem with inbound websocket subcriptions?

Is there something that needs to be configured or enabled now (compared to 4.6.2)?

Hi drmacro,

There was a bug in 5.0.12 where the websocket connection ignored authentication header. 5.0.13 fixed it. Please make sure you send the correct authorization header.

With kind regards,
Michel

8 minutes ago, Michel Kohanim said:

Hi drmacro,

There was a bug in 5.0.12 where the websocket connection ignored authentication header. 5.0.13 fixed it. Please make sure you send the correct authorization header.

With kind regards,
Michel

So, I suppose, I need to open up WireShark to see what is sent?

Cuz, the IP, user name, and password are the same.

Since I'm using the node-red-contrib-isy library I don't get to see the header...at least I don't think I do.

Edited July 10, 20187 yr by drmacro

I’m on 5.0.11 without any issues.  It sounds like 5.0.13 reverted the websocket behavior introduced in 5.0.12 back to it’s behavior in 5.0.11 but I’ll try to find some time this weekend to upgrade test out 5.0.13.

@drmacro, you mentioned you were getting the same error in relation to the variable XML.  If that’s the case, that doesn’t sound like a websocket issue but rather the contents of the XML returned for variables via REST.  It might be worth checking that the original URL’s you  accessed for integer and state variables now include a “prec” element for all variables.

13 hours ago, fahrer16 said:

I’m on 5.0.11 without any issues.  It sounds like 5.0.13 reverted the websocket behavior introduced in 5.0.12 back to it’s behavior in 5.0.11 but I’ll try to find some time this weekend to upgrade test out 5.0.13.

@drmacro, you mentioned you were getting the same error in relation to the variable XML.  If that’s the case, that doesn’t sound like a websocket issue but rather the contents of the XML returned for variables via REST.  It might be worth checking that the original URL’s you  accessed for integer and state variables now include a “prec” element for all variables.

They do.

I finally messed around with the install and remove of the isy module that the nodes were disabled and would not remove. Not sure what I did to get it in a state where it wasn't usable and could not be un-installed in node-red.

In any case, I re-built the pi SD card, installed node-red from the pi repository, then updated it to the latest, then installed the isy module. (left ISY at 5.0.13)

It now seems to be behaving and not throwing the "var" errors.

I guess I'll build some flows and see if I break it again...

@drmacro, glad to hear it's working out.  The next thing I was going to ask was whether there could have accidentally been two configuration nodes for the ISY controller created when installing since that might explain the continuous websocket connects but going nuclear and rebuilding the PI from scratch certainly works too!

19 hours ago, fahrer16 said:

@drmacro, glad to hear it's working out.  The next thing I was going to ask was whether there could have accidentally been two configuration nodes for the ISY controller created when installing since that might explain the continuous websocket connects but going nuclear and rebuilding the PI from scratch certainly works too!

I don't remember ever seeing two controller nodes.

Question: Does a flow need a ISY websocket node and, say, a device node? Or is just a device node required?

 

 

@drmacro, the controller node that gets created behind the scenes is what's actually subscribing to the websocket and processing all of the data. The nodes that are inserted into flows just provide access to what the controller node provides. 

To answer your question, a websocket node provides a means to access the raw websocket XML in a flow if desired.  A websocket node never has to be used, any node (including a device node) can be used by itself in a flow. 

14 hours ago, fahrer16 said:

@drmacro, the controller node that gets created behind the scenes is what's actually subscribing to the websocket and processing all of the data. The nodes that are inserted into flows just provide access to what the controller node provides. 

To answer your question, a websocket node provides a means to access the raw websocket XML in a flow if desired.  A websocket node never has to be used, any node (including a device node) can be used by itself in a flow. 

Ok, that's what I suspected. Thanks.

It appears that I'll be moving my motion sensor inputs (contact closures from motion sensors in the driveway) to the raspberry pi, since 5.0.13 lost the ability to update the device status in the ISY when the contacts are closed on my Aeotec Micro Switch G2 and Enerwave ZWN-RSM1. I'll sense them from the pi and push a state variable to the ISY.

Not sure...
I changed the hostname of the pi I am running node-red on.
The rest of my network handled this just fine. But, the ISY would not allow connections from node-red.

I rebooted the ISY, I power cycled the ISY, I flushed the arp tables on the pi (I guess the tables get flushed on the ISY on a reboot? power cycle?)

No go.
When I changed the name back...all was good. The pi node-red flow could now connect to the ISY.

?

@fahrer16 I tried out the node-red-contrib-isy package on my node-red server and I got it working but I encountered an error somewhat similar to those described above. 

Essentially what happened is I connected to an ISY that had no variables defined of either integer or state and I got the errors shown in the screen captures I've attached. I grabbed the return XML for /rest/vars/get/1 and /rest/vars/get/2 -- see attached screenshots -- the XML is empty.  When I went and defined two dummy variables on the ISY, the problem went away. 

This is on ISY firmware version 5.0.14 -- Please let me know if you would like more information. 

Many thanks for producing this!

Best Regards,

Mitch

 

 

Edited December 5, 20186 yr by mitchmitchell