Jump to content

Polglot V2 CAO Wireless Tags Nodeserver


Jimbo.Automates

Recommended Posts

6 hours ago, Jimbo said:

Thanks!  Yes, it can take a few for the Tag to send back the data.

Version 0.0.8 released which adds the Last Update time, and should fix issue in the traceback you posted.

I was thinking to add PingAllTags to run when a "Query" is run on a Tag Manager, but didn't have time to test it tonight.  The Reboot is also a good idea.  Added to the list Github WirelessTag Issues  Feel free to add any other issues.  

Release Notes

Upgrading

Yes, version 0.0.8 does indeed fix the traceback.  It was happening frequently prior to the update, but now it's gone!  Thanks!

EDIT: I just looked at the "Release Notes".  I understand "Seconds since epoch" as being represented by the Unix/Linux command of 'date +%s' (seconds since midnight, 1/1/1970).  I've never seen a similar ISY system value (if it's there, I don't know how to find it - the best I can find is "Seconds since start of day").  Are you going to convert that value into something the ISY natively supports?  It won't be too difficult to handle in the ISY, but it might make the data a bit more accessible to handle the conversion in the node server.  Just my 2¢...

Link to comment
Share on other sites

Sorry, the ISY doesn't have any native support for anything to represent the time, it is planned for the future. You just have to create a program to watch that it changes. I debated on just making it a toggling value to represent a heartbeat, or just seconds since last update. Not sure what is best.

Sent from my Pixel 2 XL using Tapatalk

Link to comment
Share on other sites

Seeing how the update schedule is user configurable, it seems that you'd need another field to display the update "schedule" for the user to make decisions against a heartbeat value.  Seconds since last update might be easier: simple enough to write programs against, and it would let the user make some sort of calculated decision about when to force an update.  Does that make sense?

Link to comment
Share on other sites

Heartbeats are traditionally represented by the device sending a periodic "ON" (or similar) command.  This allows one to easily create a "I got a heartbeat!" program that is triggered by that command.  I'd suggest both a timer/time-based value, and an actual heartbeat command; maximum flexibility for both those who want dirt-simple (i.e. a periodic command like battery-powered devices send) as well as those who need more information such as timing, etc.  JMO.

Link to comment
Share on other sites

8 minutes ago, mwester said:

Heartbeats are traditionally represented by the device sending a periodic "ON" (or similar) command.  This allows one to easily create a "I got a heartbeat!" program that is triggered by that command.  I'd suggest both a timer/time-based value, and an actual heartbeat command; maximum flexibility for both those who want dirt-simple (i.e. a periodic command like battery-powered devices send) as well as those who need more information such as timing, etc.  JMO.

This would do it!  I'm interested in preserving tag battery life by limiting updates, but I'd also like to get an update when some threshold external to the tag gets crossed, but only if the tag data is stale.

Again (and again and again...), thanks. 

Link to comment
Share on other sites

2 hours ago, mwester said:

Heartbeats are traditionally represented by the device sending a periodic "ON" (or similar) command.  This allows one to easily create a "I got a heartbeat!" program that is triggered by that command.  I'd suggest both a timer/time-based value, and an actual heartbeat command; maximum flexibility for both those who want dirt-simple (i.e. a periodic command like battery-powered devices send) as well as those who need more information such as timing, etc.  JMO.

Yes, currently sending commands like ON/OFF is not supported in Polyglot V2, but is being worked on by @xKing and @einstein.42. Once that is ready I will implement it as a heartbeat.

I'm storing the time of last update so it will remain across reboots of the ISY and/or Polyglot.  

Link to comment
Share on other sites

3 hours ago, Bumbershoot said:

Seeing how the update schedule is user configurable, it seems that you'd need another field to display the update "schedule" for the user to make decisions against a heartbeat value.  Seconds since last update might be easier: simple enough to write programs against, and it would let the user make some sort of calculated decision about when to force an update.  Does that make sense?

Yes, seconds since last update would make that more clear.  I decided on the time since that will retain it's value across reboots of the ISY and/or Polyglot and will make sense even if Polyglot or the nodeserver is not running.  I could create an additional value for seconds since last update which would just be current time minus last update time, and this would be updated during every shortPoll.  So you could check the seconds since last update was not greater than your update time, and that nodeserver was running using the Controller.ST value.

I also have access to the update frequency set on the tag, so I could set another driver if that threshold had passed...

Link to comment
Share on other sites

1 hour ago, Bumbershoot said:

Got it.  No "Last Update" value for tag type 32 - Water/Soil Moisture Sensor, though.

When doing the update did you tell it to update the Profile, then restart the node server, close and re-open the Admin Console?  If you did all that, then try selecting the Wireless Tags Controller in the Admin Console and click "Install Profile", then close and re-open the admin console.  I know it's there for 32 since I do have one of those.

Also, in Polyglot web under the Nodeserver -> Nodes see if that HerbPlanter has a GV13.   I had to add code to force an update on the node when the profile changed, so it's possible that didn't work for you.  If you don't see it, please PM me your debug.log file.

Link to comment
Share on other sites

I got the "Last Update" value for tag type 13, just not for tag type 32.  It does have a value for GV13, which looks to contain a "seconds since epoch" value.  Nothing in the AC for this tag type, however.  I just updated the Profile and restarted the node server and the AC.

Screen Shot 2018-03-02 at 1.25.50 PM.png

Edit: log sent.

Link to comment
Share on other sites

I'm getting occasional errors that you might be interested in.  Again, non-fatal, and they generally look like this:

2018-03-02 20:52:07,029 DEBUG    http_post: Sending: url=http://wirelesstag.net/ethClient.asmx/RequestImmediatePostback payload={"id": 0}
2018-03-02 20:52:07,262 DEBUG    http_post:  Got: code=500
2018-03-02 20:52:07,262 ERROR    http_post: Unknown response 500: http://wirelesstag.net/ethClient.asmx/RequestImmediatePostback {"Message":"Tag ID 0 not found. If already unassociated, please refresh the screen or move focus to another tag.","StackTrace":"   at MyTagList.ethClient.TagListCached.GetTagFromSlaveID(VirtualMAC vmac, Int32 slaveid, Boolean includeDeleted) in C:\\z560_backup\\MyTagList\\MyTagList\\ethClient.asmx.cs:line 1905\r\n   at MyTagList.ethClient.RequestImmediatePostback(Int32 id) in C:\\z560_backup\\MyTagList\\MyTagList\\ethClient.asmx.cs:line 3176","ExceptionType":"System.InvalidOperationException"}
2018-03-02 20:52:07,263 DEBUG    api_post_d: path=ethClient.asmx/RequestImmediatePostback got=False
2018-03-02 20:52:07,264 DEBUG    api_post_d: ret={'st': False}

Looks like this is coming from some Windows Server somewhere out in the ether.  For now, I believe this is associated with pressing the "Query" button on the individual tags.  I'll study this more, but maybe this is helpful.

 

Link to comment
Share on other sites

9 hours ago, Scottmichaelj said:

Great now I got to do math? emoji13.png

Same device, after it updated (this device is on a 4 hour update frequency).  The "Seconds Since Update" value is now very useful on it's own, with no math required! :-) 

I have currently have "Long Poll" set to 60 seconds, so "Seconds Since Update" gets a bump every minute.

This is almost too easy!

Screen Shot 2018-03-03 at 5.39.09 AM.png

Link to comment
Share on other sites

Same device, after it updated (this device is on a 4 hour update frequency).  The "Seconds Since Update" value is now very useful on it's own, with no math required! :-) 
I have currently have "Long Poll" set to 60 seconds, so "Seconds Since Update" gets a bump every minute.
This is almost too easy!
5a9aa6a0e8507_ScreenShot2018-03-03at5_39_09AM.thumb.png.5dd80438fbbcc792b5277c278edd8266.png
Awesome, yes that's what should happen. I noticed the large number in your previous post and was going to ask why it hadn't updated.

Sent from my Pixel 2 XL using Tapatalk

Link to comment
Share on other sites

11 hours ago, Bumbershoot said:

I'm getting occasional errors that you might be interested in.  Again, non-fatal, and they generally look like this:


2018-03-02 20:52:07,029 DEBUG    http_post: Sending: url=http://wirelesstag.net/ethClient.asmx/RequestImmediatePostback payload={"id": 0}
2018-03-02 20:52:07,262 DEBUG    http_post:  Got: code=500
2018-03-02 20:52:07,262 ERROR    http_post: Unknown response 500: http://wirelesstag.net/ethClient.asmx/RequestImmediatePostback {"Message":"Tag ID 0 not found. If already unassociated, please refresh the screen or move focus to another tag.","StackTrace":"   at MyTagList.ethClient.TagListCached.GetTagFromSlaveID(VirtualMAC vmac, Int32 slaveid, Boolean includeDeleted) in C:\\z560_backup\\MyTagList\\MyTagList\\ethClient.asmx.cs:line 1905\r\n   at MyTagList.ethClient.RequestImmediatePostback(Int32 id) in C:\\z560_backup\\MyTagList\\MyTagList\\ethClient.asmx.cs:line 3176","ExceptionType":"System.InvalidOperationException"}
2018-03-02 20:52:07,263 DEBUG    api_post_d: path=ethClient.asmx/RequestImmediatePostback got=False
2018-03-02 20:52:07,264 DEBUG    api_post_d: ret={'st': False}

Looks like this is coming from some Windows Server somewhere out in the ether.  For now, I believe this is associated with pressing the "Query" button on the individual tags.  I'll study this more, but maybe this is helpful.

 

Yes, this is a query of your tag with ID of 0 (zero).  The wirelesstag.net runs on windows machines :(.  Does this happen every time you query that tag, or occasionally?   You can see which Tag is id: 0, by looking at the GPV driver value in the Polyglot Nodes page.  May be I should expose that value on the ISY admin console so it's visible.

One of my concerns is that I tie the tag id, also called the slaveId to a each tag since that is used to communicate with the tag manager, but I don't know if that slaveId changes when you associate and un-associate a tag.

 

Link to comment
Share on other sites

I just installed this and it was working fine for one of my two tag managers, but now it's crashing regularly no matter what I do.  I suspect that it's somehow related to the second tag manager because the issue started happening when I tried to set "monitor tags" to "true" for that manager.  I've attached the latest debug.log here, and I'm running Polyglot v2.1.0, ISY 5.0.12, and the latest Stretch on an RPI3.

debug.log

Link to comment
Share on other sites

1 hour ago, Jimbo said:

Yes, this is a query of your tag with ID of 0 (zero).  The wirelesstag.net runs on windows machines :(.  Does this happen every time you query that tag, or occasionally?   You can see which Tag is id: 0, by looking at the GPV driver value in the Polyglot Nodes page.  May be I should expose that value on the ISY admin console so it's visible.

One of my concerns is that I tie the tag id, also called the slaveId to a each tag since that is used to communicate with the tag manager, but I don't know if that slaveId changes when you associate and un-associate a tag.

 

FWIW, I have 7 tags that have a GPV value of 0.  On the three that have GPV values > 0, the values are 1,7 and 10.

EDIT: It appears I get the error whenever I query one of the tags that have a GPV value of 0.  It also appears that, beyond occasional timeouts, querying tags that have a value > 0 results in a success.

Below is some data from one of the tags that has the GPV value of 0:

This shows up in the log when I update the tag from the Wireless Tag website:

2018-03-03 10:29:00,215 DEBUG    get_handler: command=/update
2018-03-03 10:29:00,216 DEBUG    wtController:get_handler: processing command=/update params={'ts': '2018-03-03T10:28:59 00:00', 'lux': '0', 'tagname': 'Studio', 'temp': '20.4607124328613', 'hum': '45.7120361328125', 'tagid': '12'}
2018-03-03 10:29:00,217 ERROR    wTag0F:9880b3529d9f80:Studio:get_handler: Unknown command '/update'
2018-03-03 10:29:00,218 INFO     Updating Driver 9880b3529d9f80 - CLITEMP: 68.83
2018-03-03 10:29:00,220 DEBUG    wTag0F:9880b3529d9f80:Studio:set_time: 1520101740,False
2018-03-03 10:29:00,221 INFO     Updating Driver 9880b3529d9f80 - GV13: 1520101740
2018-03-03 10:29:00,224 DEBUG    get_handler: code=200 message=Command /update success
2018-03-03 10:29:00,226 INFO     wtHandler:log_message"GET /update?tagname=Studio&tagid=12&temp=20.4607124328613&hum=45.7120361328125&lux=0&ts=2018-03-03T10:28:59+00:00 HTTP/1.1" 200 -

This is what shows up in the log when I "Query" the same tag from the AC:

2018-03-03 10:32:14,321 DEBUG    http_post: Sending: url=http://wirelesstag.net/ethClient.asmx/RequestImmediatePostback payload={"id": 0}
2018-03-03 10:32:14,536 DEBUG    http_post:  Got: code=500
2018-03-03 10:32:14,536 ERROR    http_post: Unknown response 500: http://wirelesstag.net/ethClient.asmx/RequestImmediatePostback {"Message":"Tag ID 0 not found. If already unassociated, please refresh the screen or move focus to another tag.","StackTrace":"   at MyTagList.ethClient.TagListCached.GetTagFromSlaveID(VirtualMAC vmac, Int32 slaveid, Boolean includeDeleted) in C:\\z560_backup\\MyTagList\\MyTagList\\ethClient.asmx.cs:line 1905\r\n   at MyTagList.ethClient.RequestImmediatePostback(Int32 id) in C:\\z560_backup\\MyTagList\\MyTagList\\ethClient.asmx.cs:line 3176","ExceptionType":"System.InvalidOperationException"}
2018-03-03 10:32:14,537 DEBUG    api_post_d: path=ethClient.asmx/RequestImmediatePostback got=False
2018-03-03 10:32:14,538 DEBUG    api_post_d: ret={'st': False}

Screenshot is of the Node Details.

Screen Shot 2018-03-03 at 10.34.20 AM.png

Link to comment
Share on other sites

1 hour ago, rccoleman said:

I just installed this and it was working fine for one of my two tag managers, but now it's crashing regularly no matter what I do.  I suspect that it's somehow related to the second tag manager because the issue started happening when I tried to set "monitor tags" to "true" for that manager.  I've attached the latest debug.log here, and I'm running Polyglot v2.1.0, ISY 5.0.12, and the latest Stretch on an RPI3.

debug.log

Thanks for the log.  Yes, your problems started with adding the second tag manager, but the real problem started with a Tag name that contained a space.  You will need to go into the Polyglot Wireless Tags Details Page, then click on Nodes and Delete the nodes for that tag manager.  I thought I worked around this issue, but I did not.  I know what needs to be done and will work on a fix.

However, after looking at the code,there are issues with multiple tag managers I didn't notice since I couldn't test.  I've ordered another tag manager, and it is supposed to be here today. I asked them if I could pick it up since there place was only a couple miles from my work, but they said it wasn't possible...

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...