New tagType

[gainestr]

wirelesstag.net has a new tagType=42 for their new Outdoor Probes (Temperature Only). Unable to make connection to that tagType using current code.

APICallError: Internal Server Error
Calling https://www.mytaglist.com/ethClient.asmx/LoadCurrentSensorConfig with body {"id":25} failed with status 500
at checkAPIerror (/home/pi/.node-red/node_modules/wirelesstags/lib/platform.js:650:16)
at Request._callback (/home/pi/.node-red/node_modules/wirelesstags/lib/platform.js:583:21)
at Request.self.callback (/home/pi/.node-red/node_modules/wirelesstags/node_modules/request/request.js:186:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:191:7)
at Request.<anonymous> (/home/pi/.node-red/node_modules/wirelesstags/node_modules/request/request.js:1163:10)
at emitOne (events.js:96:13)
at Request.emit (events.js:188:7)
at IncomingMessage.<anonymous> (/home/pi/.node-red/node_modules/wirelesstags/node_modules/request/request.js:1085:12)
at IncomingMessage.g (events.js:292:16)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:97...

[hlapp]

Thanks for reporting @gainestr! The problem seems to be that 42 isn't a new tagType but used to identify the current sensor (which I don't think you can buy yet, or perhaps not anymore).

I'll see what I can glean and/or reverse engineer from their demo client implementation.

[gainestr]

http://wirelesstag.net/probe.html <http://wirelesstag.net/probe.html> The above link is the new tag that I was trying to incorporate into node red. This is the information that I obtain from the tag. { "__type": "MyTagList.Tag", "notificationJS": null, "name": "Outdoor Probe", "uuid": "9dfd82f6-6ba2-41f6-a58b-f99bb8de3e38", "comment": "", "slaveId": 27, "tagType": 42, "lastComm": 131556198788745550, "alive": true, "signaldBm": -63, "batteryVolt": 3.6579206896551724, "beeping": false, "lit": false, "migrationPending": false, "beepDurationDefault": 15, "eventState": 0, "tempEventState": 0, "OutOfRange": false, "lux": 0, "temperature": 0, "tempCalOffset": 0, "capCalOffset": 0, "image_md5": null, "cap": 0, "capRaw": 0, "az2": 0, "capEventState": 0, "lightEventState": 0, "shorted": false, "thermostat": null, "playback": null, "postBackInterval": 900, "rev": 125, "version1": 4, "freqOffset": 0, "freqCalApplied": 0, "reviveEvery": 4, "oorGrace": 2, "LBTh": 2.55, "enLBN": true, "txpwr": 0, "rssiMode": false, "ds18": false, "v2flag": 2, "batteryRemaining": 1.2 } I hope this helps.

…

On Nov 19, 2017, at 8:11 PM, Hilmar Lapp ***@***.***> wrote: Thanks for reporting @gainestr <https://github.com/gainestr>! The problem seems to be that 42 isn't a new tagType but used to identify the current sensor (which I don't think you can buy yet, or perhaps not anymore). I'll what I can glean and/or reverse engineer from their demo client implementation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Af1mZ4AIuoQdxf8srXpcy-339zRedxW2ks5s4N-5gaJpZM4QSOCi>.

[hlapp]

Finally able to get back on this. Observations after some poking around:

1. The Web UI SDK download at the API docs is unchanged. Purportedly, this is what's online as the web UI, and if that works for your probe, the download is obviously not what's currently used as the web app. (Perhaps I should email them to update it.)
2. The client.js has changed, and indeed seems to have code for the outdoor probes. Interestingly, the tagType == 42 test is now used for two (entirely unrelated) sensor types, one of which remains the current sensor. I assume that's cruft.
3. The XXXXCurrentSensor* methods seem to all be gone from the API, suggesting the current sensor is discontinued if it ever was supported. (Perhaps something they had in development?).

I created a separate issue for retiring the *CurrentSensor* API methods, and will investigate the changes in the client.js code.

[hlapp]

@gainestr I notice that you have "temperature": 0 in the tag's data block. If I read the vendor-published client.js correctly, that must mean that you haven't (or hadn't) activated the external thermocouple probe yet. (Or alternatively, you were measuring the temperature of an ice bath.)

I.e., can you confirm that at least at the time the app showed the temperature as either 0.0°C, 32.0°F, or awaiting external probe activation?

[gainestr]

I have the outdoor probe attached to the DS18B20 temperature probe and not the external thermocouple probe. I had been playing around with the probe and apparently had reset it. I can confirm that at the time I sent the data points that the probe apparently had not been activated. I am currently getting temperature readings. Here is the latest data points that I am getting from the my.wirelesstag.net <http://my.wirelesstag.net/> GetTagList Network resource: { "__type": "MyTagList.Tag", "notificationJS": "", "name": "Outdoor Probe", "uuid": "9dfd82f6-6ba2-41f6-a58b-f99bb8de3e38", "comment": "", "slaveId": 27, "tagType": 42, "lastComm": 131589164099531280, "alive": true, "signaldBm": -78, "batteryVolt": 3.599726915359497, "beeping": false, "lit": false, "migrationPending": false, "beepDurationDefault": 15, "eventState": 0, "tempEventState": 0, "OutOfRange": false, "lux": 0, "temperature": 20.5625, "tempCalOffset": 0, "capCalOffset": 0, "image_md5": null, "cap": 0, "capRaw": 0, "az2": 0, "capEventState": 0, "lightEventState": 0, "shorted": false, "thermostat": null, "playback": null, "postBackInterval": 900, "rev": 125, "version1": 4, "freqOffset": 422, "freqCalApplied": 3635, "reviveEvery": 255, "oorGrace": 2, "LBTh": 2.55, "enLBN": true, "txpwr": 18, "rssiMode": false, "ds18": true, "v2flag": 2, "batteryRemaining": 1.17 }

…

On Dec 27, 2017, at 11:26 AM, Hilmar Lapp ***@***.***> wrote: @gainestr <https://github.com/gainestr> I notice that you have "temperature": 0 in the tag's data block. If I read the vendor-published client.js correctly, that must mean that you haven't (or hadn't) activated the external thermocouple probe yet. (Or alternatively, you were measuring the temperature of an ice bath.) I.e., can you confirm that at least at the time the app showed the temperature as either 0.0°C, 32.0°F, or awaiting external probe activation? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Af1mZxbBMtt9JAHcsc1vBzevayQVgR4Vks5tEn3DgaJpZM4QSOCi>.

[hlapp]

@gainestr thanks, this helps. For confirm I am understanding correctly what you're saying and what the vendor's client.js seems to be saying, the probe model you have is the "Basic" one, and isn't the one that would allow you to choose connecting either a DS18B20 or a k-type Thermocouple probe? (I'm inferring this from rev & 0x0F === 0x0D for your "rev": 125.

It seems in order to have the ability to switch between DS18B20 and thermocouple, rev & 0x0F === 0x0F would have to hold.

[hlapp]

See #44 for some challenges and considerations for how best to implement support for these probes. Comments and feedback are certainly welcome.

[hlapp]

Basic support for the Outdoor tags should be available now (caveat being that as noted in #45, I'll only be able to thoroughly test once I receive the Outdoor tags I've now ordered). Released as part of v0.7.0, which is available from npm as well.

I'm going to close this, even though there are some r/w operations (in particular switching to the DS18B20 for the Thermocouple and GE Protimeter models) that aren't covered yet. I'm leaving #44 open for now as a reminder, though I think this is outside of the scope of what you were looking for.