Brultech - How are GEM nodes supposed to look in the ISY console?

[Scyto]

 

Your issue is:

2015-11-26 11:11:20 - ISY Error: The remote server returned an error: (404) OK. (ns/1/nodes/n001_gem/report/status/ST/121.5/72)

 

Nothing else will write because you error out, it has nothing to do with gem/data/child nodes.  I don't know why it's giving a 404.  Are you running 5.0.2?  This was a bug in 5.0.1

 

Yes 5.0.2 

 

please see the screenshots and attachments in these two posts - they give as much detail as i know how to collect:

 

http://forum.universal-devices.com/topic/17339-how-are-gem-nodes-supposed-to-look-in-the-isy-console/?p=155462

http://forum.universal-devices.com/topic/17339-how-are-gem-nodes-supposed-to-look-in-the-isy-console/?p=155481

[Scyto]

I just deleted the GEM device from nodelink and the nodes from the ISY and now the test node is working perfectly, i will try re-adding the lat and lon and see if it continues to work after that..

 

--edit1--

 

I removed the test device and recreated (called it datetime) and configured the lat and lon it updated on start of population but now it is stalled again, i will retry.

 

--edit2--

i removed the date time device and recreated and it is now working perfectly - updates once a minute. I can try adding the lat and lon to see if that breaks it again if you like?

 

I assume this validates that in general the ISY is ok?

 

--edit 3--

adding the lat and lon, clicking install ISY node and then doing an immediate restart of nodelink seems to now have the azimuth data updating too, i am wondering if this is a strict sequence issue, i will try creating the GEM nodes yet again and this time as soon as the tree has populated i will restart nodelink.

 

--edit 4--

removing the new GEM device unblocked the process - now date/time/sunpos all updating ok. 

[io_guy]

Getting a 404 means the node doesn't exist in the ISY. If your nodes don't install correctly into the ISY the it will be broken.

 

Unfortunately there's not much I can do until UDI fix bugs. Right now adding a node that already exists causes a 404 as well so I have no way to distinguish. There's also no way to see what's installed and repair.

[Scyto]

Ok, i understand the nature of beta software

 

I assume me looking at http://isy/rest/nodesto see if the nodes are there or not is not good enough?

Adding nodes is not failing AFAIK see, they all appear on that URL and all seem to be well formed - I check the nodes URL before i add and there are no nodes returned in the nodelist and when i add there are no add-errors in the log for the nodes.

 

I note that http://192.168.1.97/rest/nodes/n001_gem returns:

 

<nodeInfo>

<node flag="128" nodeDefId="GreenEye" nls="143">

<address>n001_gem</address>

<name>n001_gem</name>

<family instance="1">10</family>

<type>1.1.0.0</type>

<enabled>true</enabled>

<deviceClass>0</deviceClass>

<wattage>0</wattage>

<dcPeriod>0</dcPeriod>

<pnode>n001_gem</pnode>

</node>

<properties/>

</nodeInfo>

 

but that http://192.168.1.97/rest/nodes/n001_gem/report

 

<RestResponse succeeded="false">

<status>404</status>

</RestResponse>

 

-I guess you already know this?  I think you might be saying there is an issue with an internal nodes structure on my ISY?

 

Also if you get a 404 on one node why not keep trying the other nodes?  We know my date/time node works just fine!?  The GEM node fault shouldn't block writing to the datetime node IMO.

[io_guy]

I get the same reports back as you. 

 

For some reason you're getting a 404 when trying to write a variable.  You can try:

- Use a web browser to send the same failed command and see what happens

- Move NodeLink to a different computer to try

 

I stop on 404 because I use a FIFO buffer to control ISY sends.  This ensures I don't flood/kill the ISY and also ensures the timing of all messages (important for things like alarms).  Allowing it to continue on fail would be a Band-Aid for whatever the underlying issue is.

[Scyto]

moving nodelink from pi2 to windows box made no difference (though easier to look at log as i have console access!)

 

Using a chrome browser made a big difference.

 

• I manually created a 33rd GEM channel (under the main gem node the nodelink server had created) using chrome with the URL "http://isy/rest/ns/1/nodes/n001_gem_chan33/add/GreenEyeChannel?primary=n001_gem&name=n001_gem_chan33&nls=143C"to prove I could make a node showup in the ISY
• When i tried to access "http://isy/rest/ns/1/nodes/n001_gem/report/status/ST/121.5"in chrome i got a password prompt in the browser, my ISY username and password did not work.
• I then added the username and password to the Node Server Configuration dialog in the ISY for [01] isylink (network) and lo and behold i managed to populate the entry - the nodelink server still got an error
• I then removed the username and password on the Node Server Config and chrome still let me edit the parameter (though the nodelink server would not)
• I switched to EDGE browser incase some sort of browser keep alive was helping - i could still set parameters without being prompted for password
• I then populated one of the channels to make sure i could do this for other channels.

 

looks like some sort of weird auth bug?  

 

--edit--

what does the /72 at the end of the command in the log mean?

 

when i do "http://192.168.1.97/rest/ns/1/nodes/n001_gem/report/status/ST/110.1/72"i get prompted for my password and username in the browser and it works (irrespective of the setting on the node server config page).  I i omit the /72 the node config server page has to the password and username.  

 

Also i notice that in the logs you have a space carriage return before the /72 so the command is this 'http://192.168.1.97/rest/ns/1/nodes/n001_gem/report/status/ST/110.1%0D%0A/72" whichif i use in the browser doesn't work?

 

I also verified this from a powershell using Invoke-RestMethod - and i get a (404) not found error - could an errant space be slipping in somehow?

[io_guy]

If it was an auth bug you "should" get a 401 back.  I say should because this really depends on how UDI coded it.  If it was auth I would expect that no call NodeLink makes would work (including adding nodes and the ISY Data updates).

To my knowledge no one else using NodeLink has an issue with user/pass.  NodeLink expects both to be blank as I do not send across an auth header.

 

For this not to work on either machine is bizarre.  I test on both here without issue.

[Scyto]

Are you sure the space carriage return in the command that nodelink is sending is expected?  I can toggle between working / not working by adding and removing the carriage return in the browser URL.  Here is the packet, you can see the space carriage encoded in the packet - is this the command you think you are sending, because it is what my edition of nodelink is sending.

 

245 15.165817 192.168.1.204 192.168.1.97 HTTP 195 GET /rest/ns/1/nodes/n001_gem/report/status/ST/122.0%0D%0A/72 HTTP/1.1  because this command in a browser  ALWAYS fails with 404

 

If one removes the space carriage return it ALWAYS works - like this : /rest/ns/1/nodes/n001_gem/report/status/ST/122.0/72

 

I can send you the wireshark traces if that would be helpful?  

 

(FYI my bad - the omission of the /72 at the end entirely generates the spurious and odd auth prompt that can be fixed with setting the username and password on the nodeserver in the ISY - but i guess the /72 is the right way to go there  so please ignore my auth comments.)

 

--edit 1--

oh i see there is a /xx at the end of every command (like 25, 72, 14 whatever) - so the auth issue was caused by me omitting that.

i just looked at the startup wireshark traffic for nodelink  all the write commands that worked have no space carriage return encoded in the URL the failing one does.

 

Is there something i could have done to cause the space carriage return in the GEM stuff?

 

--edit 2--

shows you how non-existent my coding skills are i realize that "%0D%0A" is a carriage return - i am unclear if one can send those in a URI?

[io_guy]

I don't send any carriage returns in the middle of my calls.

 

For some to be chopped and some not I'm wondering if you packets are getting chopped up on the TCP level (your network).

[Scyto]

Just what i was thinking this is my packet, it is the ASCII format packet, the V is the last item on the packet and there appears to be a carriage return at the end of the packet line.

I don't send pulse counters or temps on my packets, so i am not sure what is the normal end of the packet ( i got this directly from the GEM)

 

<html><br><br><h2>Packet</h2><br><br>n=01000029&m=6946&wh_1=277547.22&p_1=1563&wh_2=2574.75&p_2=2&wh_3=137278.15&p_3=0&wh_4=13325.07&p_4=105&wh_5=1884.29&p_5=2&wh_6=1727.59&p_6=4&wh_7=4144.65&p_7=4&wh_8=10636.73&p_8=17&wh_9=863.86&p_9=2&wh_10=2018.85&p_10=9&wh_11=4391.97&p_11=263&wh_12=538.47&p_12=2&wh_13=25.44&p_13=0&wh_14=23.30&p_14=0&wh_15=534.54&p_15=4&wh_16=287.63&p_16=0&wh_17=1357.06&p_17=0&wh_18=9865.29&p_18=61&wh_19=1887.05&p_19=3&wh_20=172.01&p_20=1&wh_21=239.58&p_21=2&wh_22=156.84&p_22=1&wh_23=147.07&p_23=1&wh_24=7440.49&p_24=112&wh_25=2279.52&p_25=111&wh_26=134.79&p_26=0&wh_27=1885.34&p_27=3&wh_28=3071.97&p_28=26&wh_29=46239.19&p_29=636&wh_30=18066.96&p_30=147&wh_31=880.40&p_31=7&wh_32=31.61&p_32=0&v=121.8

<br><br><a href="3?SPK="><h3>Refresh Packet</h3></a><br><br><a href="3"><h3>Return</h3></a></html>

[Scyto]

Changing to packet type to type 14 and setting everything up from scratch worked.

 

I don't know why on my GEM the ASCII packet format 2 has a carriage return after the voltage - but it does, not sure if you want to account for that possibility and remove any carriage returns from the incoming format or reccomend folks not to use  format 2?

[io_guy]

We found er!  I can reproduce this by copying your setup with ASCII.  I'll fix it in the next version.  For now, switching to Seg14 should fix it.

[Scyto]

Yay!  i am very proud of myself, haven't done wire level tracing for a real error in probably over a decade!

 

(i once had one where the packet getting sent to the NIC driver by the OS and the packet hitting the wire were different - but this only happened on one of 25 identical machines, packets were identical on 25 machines except for one field - name) - when that packet on that machine passed through the TCP offload engine on the hardware it corrupted the packet.  adaptec never agreed it was a bug - the [censored], guess that's why they are not in the networking game anymore!