Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problem with Jetstream Driver
Those are value rejected errors. What value are you writing to D053GarageDoorsRecess? That's the one that is getting the rejected value error.
Dean Roddey
Software Geek Extraordinaire
It happens no matter what value I send i.e. 0-99.

The Jetstream serial bridge actually controls these devices properly. It's just that CQC throws an error.

It happens with every device where the device ID > 50. When I enroll a device in Jetstream, it automatically assigns a Device ID which equals the highest existing ID + 1. Since I now have Device IDs above 50, every new device I enroll has the same problem. If I unenroll an device that works fine (e.g. ID <50) and then re-enroll the device, it will get a new ID above 50, and writing to that same device that previously worked fine will now produce the error.
My Other web server is Dropbox.
OK, so it sets the value rejected status if it is unable to get the response from the send of the command. That is done via WaitForMessage(). That guy calls WaitMessage to wait for a message. There's nothing in that that I can see that could be remotely related to a number in the message. If it gets a message it calls ProcessMessage() to handle it.

In ProcessMessage that's where it extracts values from the message. So, assuming this is a device level message being responded to, it extracts an id and a level. The id obviously is the one of interest. It gets three characters from the msg starting at index 3. But, if that were wrong it could only cause an exception, and no exception path sets ValueRejected. So that can't be it.

The msg it builds up is the id plus the level plus the rate. The id is obviously the thing being affected. But strangely there's nothing there that could change at the 50 crossover point. The id is 3 digits with leading zeros. So it checks is it less than 10, add two leading zeros, else is it less than 100, add 1 leading zero, else none.

So that cannot possibly be a point of failure by crossing over that 50 line. I honestly can't see any way that anything could change at particular crossover point.

Given that the operation works, it seems like it has to be that the device changes the format of the message it sends out in response once the 50 point is hit somehow. The driver assumes that the msg it gets back is a direct echo of the message it sent. If that's not true, it will think it never got a response, even if it did. Given that no other error seems to occur, either the device stops responding at 50 or it no longer echos the msg back exactly as it was sent.

That's almost got to be what it is. Nothing else makes any sense. So, the driver logs messages if it is in high verbosity. Flush the logs, put the driver into high, then quickly do a field write to one that fails, then take it back out of verbose logging and get a lot dump.

We should see the outgoing and incoming messages and can see if they are really different. Or, if it just never responded.
Dean Roddey
Software Geek Extraordinaire
The file I referenced earlier is a high verbosity dump with both a successful and a failed command. Do you need more?
My Other web server is Dropbox.
Oh, OK. It looks like the device didn't respond. In the good one he sent:

<Send> Msg sent: [^E0509900]

and got back (it's actually a slightly modified version but the original content is in there.)

<Ver0.6.0GetMessage>: Received DEV05099

In the bad one, he sends:

<Send> Msg sent: [^E0539900]

and the received line shows :

<Ver0.6.0GetMessage>: Received

Which means it didn't get anything back in the timeout. It also waits for async msgs in the Poll() so even if we had timed out slightly early, it would have shown up quickly after that in the poll but it doesn't.

So it looks like there is no response from the device. Or, if it is, it's mangled in some way such that it does look like a CR/LF terminated line as it needs to.

Can you maybe try it with a terminal program. The messages sent are literally the ones above. It doesn't appear to require any line termination, but probably a CR/LF won't hurt it. That way we could get a second opinion about what is coming back, if anything.
Dean Roddey
Software Geek Extraordinaire
I can't seem to get putty to connect. Would I probably need to disconnect CQC first?
My Other web server is Dropbox.
You will need to pause the CQC driver prior to trying to connect via putty.

Possibly Related Threads...
Thread Author Replies Views Last Post
  "Client Side Driver Directory Could Not be Cleaned Out" TurboSam 15 377 09-27-2018, 01:43 PM
Last Post: TurboSam
  CML Driver IDE docs - where? rbroders 1 120 09-18-2018, 05:41 PM
Last Post: Dean Roddey
  Timer Driver Question kblagron 5 197 09-14-2018, 02:43 AM
Last Post: znelbok
  reset driver statistics? rbroders 9 516 09-11-2018, 07:50 PM
Last Post: Dean Roddey
  Driver Configuration w/8 prompts rbroders 1 315 09-03-2018, 09:28 PM
Last Post: Dean Roddey
  Driver info/stats rbroders 6 449 09-02-2018, 08:34 PM
Last Post: Dean Roddey
  Sonos Driver zra 3 271 09-01-2018, 03:09 PM
Last Post: Dean Roddey
  HTTP Get driver not working znelbok 10 650 08-28-2018, 10:10 AM
Last Post: Dean Roddey
  Can't add fields to ElkDev driver rbroders 4 361 08-07-2018, 06:24 PM
Last Post: Dean Roddey
  Possible to copy all the name in a driver so can paste is elsewhere? ghurty 11 770 07-14-2018, 05:24 PM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)