#10
- Created on2011-07-03 07:04
- Reported by
- StatusFixed
- PriorityHigh (2)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Trigger executed macro : unknown, address 0x7ff
--- In heyu_users@yahoogroups.com, "David OConnell" <daoconnell@...> wrote:
>
> Can anyone explain this.
>
> If I do a "heyu bright e4 8" I get
>
> 03/14 22:36:16 Trigger executed macro : unknown, address 0x7ff
> 03/14 22:36:16 Poll received unknown value (1 bytes), leading byte = ff
> 03/14 22:36:16 Poll received unknown value (1 bytes), leading byte = 0
>
> In monitor, whether from command line or from a script
>
> If I use another value for bright e.g. "heyu bright e4 9" it works as normal
> If I use another house code e.g. "heyu bright a4 8" . it works as normal
> If I use another unit code e.g. "heyu bright e2 8" I get this strange output in the monitor
>
> It seems to have only started since I upgraded to heyu 2.10 rc but I can't be entirely sure of that
>
> Thanks
>
> Can anyone explain this.
>
> If I do a "heyu bright e4 8" I get
>
> 03/14 22:36:16 Trigger executed macro : unknown, address 0x7ff
> 03/14 22:36:16 Poll received unknown value (1 bytes), leading byte = ff
> 03/14 22:36:16 Poll received unknown value (1 bytes), leading byte = 0
>
> In monitor, whether from command line or from a script
>
> If I use another value for bright e.g. "heyu bright e4 9" it works as normal
> If I use another house code e.g. "heyu bright a4 8" . it works as normal
> If I use another unit code e.g. "heyu bright e2 8" I get this strange output in the monitor
>
> It seems to have only started since I upgraded to heyu 2.10 rc but I can't be entirely sure of that
>
> Thanks
Leave a comment
on 2011-07-03 07:11 *
By heyu_users
Assigned to set to Janusz Krzysztofik
Milestone set to 2.10
Priority changed from Normal (3) to High (2)
Status changed from New to Accepted
--- In heyu_users@yahoogroups.com, "Janusz" <jkrzyszt@...> wrote:
>
> Hi David and all,
> This looks like a bug in the new functionality of the engine, dealing
> with checksums the relay is now passing unmarked to the spool file.
> Apparently, a checksum must happen to be recognized as a macro report
> startup byte, before it is checked against against an expected
> checksum value. I have to take a closer look at it.
>
> This seems of minor severity at a first glance, but I'm not really
> sure what consequences of the bug could happen, so have to advise you
> not using 2.10-rc1 in production environments, unless suffering
> hardly form the well known "Poll received unknown value ..." issues
> before, which this release is supposed to resolve.
>
> Thanks,
> Janusz
>
> Hi David and all,
> This looks like a bug in the new functionality of the engine, dealing
> with checksums the relay is now passing unmarked to the spool file.
> Apparently, a checksum must happen to be recognized as a macro report
> startup byte, before it is checked against against an expected
> checksum value. I have to take a closer look at it.
>
> This seems of minor severity at a first glance, but I'm not really
> sure what consequences of the bug could happen, so have to advise you
> not using 2.10-rc1 in production environments, unless suffering
> hardly form the well known "Poll received unknown value ..." issues
> before, which this release is supposed to resolve.
>
> Thanks,
> Janusz
on 2011-07-03 07:13 *
By heyu_users
--- In heyu_users@yahoogroups.com, "David O'Connell" <daoconnell@...> wrote:
>
> Hi Janusz
>
> Yes I've installed 2.9.3 and the problem has stopped. Strange how it only
> effected house code E and Bright 8 together
>
> Thanks David
>
> Hi Janusz
>
> Yes I've installed 2.9.3 and the problem has stopped. Strange how it only
> effected house code E and Bright 8 together
>
> Thanks David
on 2011-07-03 07:14 *
By heyu_users
--- In heyu_users@yahoogroups.com, "Janusz" <jkrzyszt@...> wrote:
>
> Just a coincidence: outgoing housecode E bright 8 command checksum the CM11A
> responds with, must be the same as the first byte of a macro execution report.
>
> Thanks,
> Janusz
>
> Just a coincidence: outgoing housecode E bright 8 command checksum the CM11A
> responds with, must be the same as the first byte of a macro execution report.
>
> Thanks,
> Janusz
on 2011-07-30 10:34 *
By Janusz Krzysztofik
(In revision:eb484a85819b71757c96a22fbf023e8c5484e088) Fix 'Poll received unknown value' wrong byte count
If it ever happens that a broken sequence, other than an incoming
powerline signal, is fetched from the Heyu spool file by the engine or
monitor, the check4poll() function puts all 0xff bytes collected so far
back to the buffer and passes them, together with the following byte,
for being reported with the "Poll received unknown value ..." error
message. However, while doing this, the actual length of the broken
sequence is not set, moreover with the variable expected to carry the
length being used meanwhile for temporary storing the last byte value.
As a result, the "Poll received unknown value ..." messages provide
incorrect sequence lengths if different from 1 byte.
While this bug doesn't affect Heyu ability to recognise and interpret
the spool file contents correctly, it makes it harder to diagnose other
problems, either hardware related or caused by other bugs, which
exhibit themselves with "Poll received unknown value ..." reports.
This issue has just been discovered while hunting for such other bugs
(see #10).
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:fixes
If it ever happens that a broken sequence, other than an incoming
powerline signal, is fetched from the Heyu spool file by the engine or
monitor, the check4poll() function puts all 0xff bytes collected so far
back to the buffer and passes them, together with the following byte,
for being reported with the "Poll received unknown value ..." error
message. However, while doing this, the actual length of the broken
sequence is not set, moreover with the variable expected to carry the
length being used meanwhile for temporary storing the last byte value.
As a result, the "Poll received unknown value ..." messages provide
incorrect sequence lengths if different from 1 byte.
While this bug doesn't affect Heyu ability to recognise and interpret
the spool file contents correctly, it makes it harder to diagnose other
problems, either hardware related or caused by other bugs, which
exhibit themselves with "Poll received unknown value ..." reports.
This issue has just been discovered while hunting for such other bugs
(see #10).
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:fixes
on 2011-07-31 05:00 *
By Janusz Krzysztofik
(In revision:24732dff7b07d300daca6d296c07b31fb43e5a49 (git: 2)) Fix 'Poll received unknown value' wrong byte count
If it ever happens that a broken sequence, other than an incoming
powerline signal, is fetched from the Heyu spool file by the engine or
monitor, the check4poll() function puts all 0xff bytes collected so far
back to the buffer and passes them, together with the following byte,
for being reported with the "Poll received unknown value ..." error
message. However, while doing this, the actual length of the broken
sequence is not set, moreover with the variable expected to carry the
length being used meanwhile for temporary storing the last byte value.
As a result, the "Poll received unknown value ..." messages provide
incorrect sequence lengths if different from 1 byte.
While this bug doesn't affect Heyu ability to recognise and interpret
the spool file contents correctly, it makes it harder to diagnose other
problems, either hardware related or caused by other bugs, which
exhibit themselves with "Poll received unknown value ..." reports.
This issue has just been discovered while hunting for such other bugs
(see #10).
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:jk/chksum
If it ever happens that a broken sequence, other than an incoming
powerline signal, is fetched from the Heyu spool file by the engine or
monitor, the check4poll() function puts all 0xff bytes collected so far
back to the buffer and passes them, together with the following byte,
for being reported with the "Poll received unknown value ..." error
message. However, while doing this, the actual length of the broken
sequence is not set, moreover with the variable expected to carry the
length being used meanwhile for temporary storing the last byte value.
As a result, the "Poll received unknown value ..." messages provide
incorrect sequence lengths if different from 1 byte.
While this bug doesn't affect Heyu ability to recognise and interpret
the spool file contents correctly, it makes it harder to diagnose other
problems, either hardware related or caused by other bugs, which
exhibit themselves with "Poll received unknown value ..." reports.
This issue has just been discovered while hunting for such other bugs
(see #10).
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:jk/chksum
(In revision:65cf7f2484a9fe13a182e0cc26b8765c8dc07d07 (git: 2)) Prevent from checksums being incorrectly recognised as events
It may happen that a checksum value can match one of special bytes used
by the CM11A interface to signal events to the user. Since commit
2cd54bdeb9, "Engine: use chksum_alert for all CM11 commands", some of
these values may be never recognized as checksums, resulting in the
engine incorrectly interpreting the data stream.
Fix this issue by moving checksum matching in front of any other
matching of bytes received.
Test #10
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:jk/chksum
It may happen that a checksum value can match one of special bytes used
by the CM11A interface to signal events to the user. Since commit
2cd54bdeb9, "Engine: use chksum_alert for all CM11 commands", some of
these values may be never recognized as checksums, resulting in the
engine incorrectly interpreting the data stream.
Fix this issue by moving checksum matching in front of any other
matching of bytes received.
Test #10
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:jk/chksum
on 2011-07-31 05:23 *
By Janusz Krzysztofik
Submitted for review. View.
on 2011-07-31 05:29 *
By Janusz Krzysztofik
Attachment 0002-Use-a-negative-value-for-no-checksum-alert.patch added
on 2011-07-31 05:29 *
By Janusz Krzysztofik
Attachment 0003-Fix-0xff-checksum-before-triple-0xff-mark-case.patch added
on 2011-07-31 05:29 *
By Janusz Krzysztofik
Attachment 0004-Fix-single-0xff-checksum-processing.patch added
on 2011-07-31 05:29 *
By Janusz Krzysztofik
Attachment 0005-Prevent-from-checksums-being-incorrectly-recognised-.patch added
on 2011-07-31 05:34 *
By Janusz Krzysztofik
Hi,
When applying from the above file attachments (on top of 2.10-rc1), please apply file:Fix-Poll-received-unknown-value-wrong-byte-count.patch first.
Thanks,
Janusz
When applying from the above file attachments (on top of 2.10-rc1), please apply file:Fix-Poll-received-unknown-value-wrong-byte-count.patch first.
Thanks,
Janusz
on 2011-08-07 03:29 *
By Janusz Krzysztofik
(In revision:425d9ad1ba379a17ee618676c7c059b3aca2d384) Prevent from checksums being incorrectly recognised as events
It may happen that a checksum value can match one of special bytes used
by the CM11A interface to signal events to the user. Since commit
2cd54bdeb9, "Engine: use chksum_alert for all CM11 commands", some of
these values may be never recognized as checksums, resulting in the
engine incorrectly interpreting the data stream.
Fix this issue by moving checksum matching in front of any other
matching of bytes received.
Test #10
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:for-next
It may happen that a checksum value can match one of special bytes used
by the CM11A interface to signal events to the user. Since commit
2cd54bdeb9, "Engine: use chksum_alert for all CM11 commands", some of
these values may be never recognized as checksums, resulting in the
engine incorrectly interpreting the data stream.
Fix this issue by moving checksum matching in front of any other
matching of bytes received.
Test #10
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:for-next
(In revision:acb1dd15dd3fcb913c929b4bea96edd544f6151a) Prevent from checksums being incorrectly recognised as events
It may happen that a checksum value can match one of special bytes used
by the CM11A interface to signal events to the user. Since commit
2cd54bdeb9, "Engine: use chksum_alert for all CM11 commands", some of
these values may be never recognized as checksums, resulting in the
engine incorrectly interpreting the data stream.
Fix this issue by moving checksum matching in front of any other
matching of bytes received.
Fixes #10
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:for-next
It may happen that a checksum value can match one of special bytes used
by the CM11A interface to signal events to the user. Since commit
2cd54bdeb9, "Engine: use chksum_alert for all CM11 commands", some of
these values may be never recognized as checksums, resulting in the
engine incorrectly interpreting the data stream.
Fix this issue by moving checksum matching in front of any other
matching of bytes received.
Fixes #10
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:for-next
on 2011-08-20 15:52 *
By Janusz Krzysztofik
(In revision:eb484a85819b71757c96a22fbf023e8c5484e088 (git: 2)) Fix 'Poll received unknown value' wrong byte count
If it ever happens that a broken sequence, other than an incoming
powerline signal, is fetched from the Heyu spool file by the engine or
monitor, the check4poll() function puts all 0xff bytes collected so far
back to the buffer and passes them, together with the following byte,
for being reported with the "Poll received unknown value ..." error
message. However, while doing this, the actual length of the broken
sequence is not set, moreover with the variable expected to carry the
length being used meanwhile for temporary storing the last byte value.
As a result, the "Poll received unknown value ..." messages provide
incorrect sequence lengths if different from 1 byte.
While this bug doesn't affect Heyu ability to recognise and interpret
the spool file contents correctly, it makes it harder to diagnose other
problems, either hardware related or caused by other bugs, which
exhibit themselves with "Poll received unknown value ..." reports.
This issue has just been discovered while hunting for such other bugs
(see #10).
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:jk/freopen
If it ever happens that a broken sequence, other than an incoming
powerline signal, is fetched from the Heyu spool file by the engine or
monitor, the check4poll() function puts all 0xff bytes collected so far
back to the buffer and passes them, together with the following byte,
for being reported with the "Poll received unknown value ..." error
message. However, while doing this, the actual length of the broken
sequence is not set, moreover with the variable expected to carry the
length being used meanwhile for temporary storing the last byte value.
As a result, the "Poll received unknown value ..." messages provide
incorrect sequence lengths if different from 1 byte.
While this bug doesn't affect Heyu ability to recognise and interpret
the spool file contents correctly, it makes it harder to diagnose other
problems, either hardware related or caused by other bugs, which
exhibit themselves with "Poll received unknown value ..." reports.
This issue has just been discovered while hunting for such other bugs
(see #10).
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Branch:jk/freopen