Need Help on Weeder WTDIN

[james at sentman.com]

> On Oct 10, 2022, at 5:25 PM, George Handley <12508handwork at gmail.com> wrote:
> 
> James,
> 
> I just got finished sending you the email below, and upon sending it to you I looked at my copy, and it appeared to be in all Chinese characters, so I’m sending it again under a different email address.
> 
> James,
> 
> I thought for  sure I’d hear fro you over the weekend or at least today, but theres been no response to my emails requesting help.
> 
> I have tried each of your suggestions after first hooking your a WTDIN card directly to my main XTension machine and can make a WTDIN crudely communicate by tricking tt using the 1 off theory. From that I’ve already told you the WTDIN card communicates just fine with XTension, but what it does is not. I’ve told you about how it appears to be a “1 off” problem inside your supporting Weeder software, and when queried, Terry says it has to be something inside your weeder.isf plugin software. I even poked around inside your Plugins/weeder.isf folder and looked around, but without any guidance from you, it is totally greek to me. I need your help
> 
> I’ve waited all last week, last weekend and today and I don’t know why you’re ignoring me. Is there something from this end I can send you to allow you to help?
> 
> Terry says my problem all along is that his DIO cards have no protection from lightning, and that lightning even a mile away could burn up of his DIO cards, even ones that are behind a regulating UPS which I thought was impossible. 
> 
> Could you please step in a straighten this out!


The Weeder plugin predates the python plugin API and so is a binary compiled app and you can’t make any changes to it without the source code to re-compile so wandering through the plugin folder won’t show you anything helpful.

I cannot immediately explain the weird data that is received from yours in any way that makes sense to me other than interference somewhere. The software has not changed significantly in a hugely long time except where I added extra logging to try to figure out what was going on with your system. It’s made all the more strange by the fact that I currently have 4 of the wtdin cards attached to my system. 2 of them connected directly over a USB/Serial adaptor and 2 in a different location on a wiznet card. They both function perfectly and have for years and years with every version of the software. They are connected to the main alarm system panel in the house for all the wired inputs to that, and then in the garage panel for all the extra inputs that are in there. I do not get any of these errors, not even fleetingly. I have scanned my saved log files back for years to try to find anything similar and there just isn’t anything.

I have read through the code so often I can see it in my sleep and I haven’t found anything that is even remotely possible for what is happening and that is why I keep insisting that it must be a hardware or noise or power supply issue as those exact cards work perfectly here. 

I am going to add some further logging to compare the raw binary values from the data stream to the values that are extracted to see if there isn’t some text encoding issue where some of the data is considered to be UTF-8 and other considered to be binary or something odd like that because text encoding has so often caused me so much pain in the past but all the data from the devices is in ascii so should be indistinguishable between the two, but the weird accented characters are what can happen if it is trying to interpret binary data into text. But there should not be any binary data in these streams. it’s just regular old ascii bytes, real old school. You have to have a value outside the normal ascii in order to confuse text encoding and we just aren’t dealing with any of that here. 

So the short answer is that I will add some more logging to it and include that in the next build sometime over the weekend. But I do not have high hopes that will lead to anything other than being able to even more specifically point the finger at bogus data coming over the serial lines. I may have more questions for you as i add that to try to figure out if there is anything I can think of to narrow down what might be different between your system and mine even though we’re using the same connection methods and the exact same model cards. Something has to be different and as of this moment I have no idea what it might be. There is bogus data being received over the serial port at both ends. XTension sees bogus data and the weeder card occasionally sends an error upstream that it received some bogus data. It’s funny that the error message (just the “?” that it sends) is received and logged by XTension perfectly. 

I’m not sure what else Terry can tell you at this point, just as I’m not sure what I can tell you. I run 4 of those cards and they have never logged an error except during the thunderstorm a few years ago that took one of them out. Never, not one even missed poll in the last 5 years. They are exactly the same cards you’re using connected in both different ways that you are using. Something is different, we need to find out what it is.