Rickedb / OpenProtocolInterpreter

Converts the ugly ASCII package that came from Open Protocol to an object
MIT License
144 stars 72 forks source link

MID 0008 Relay Subscribe MID 0217 #113

Closed sosborne-control2k closed 3 weeks ago

sosborne-control2k commented 1 month ago

Hi,

am trying to send a Relay (MID 0217) subscription by using MID 0008. MID 0008 works successfully for Tightening Result (MID 1201), but for Relay subscription I get MID 0004 response:

002600040010 00 000801

I suspect the issue is the Extra Data that should be provided - the Atlas Copco documentation doesn't cover any Extra Data for the Relay MID - does anyone have an example of a successful Relay subscription using MID 0008?

Rickedb commented 1 month ago

Hello,

Mid0008 is a bit tricky sometimes, because the errors aren't clear most of the times. The invalid data error might pop up sometimes when the controller/firmware does not support it via Mid0008 or it could be the Extra data that might be wrong, which I recommend you to try building the plain text of the string once to check if it is ok.

Which controller are you integrating with?

sosborne-control2k commented 1 month ago

Hi,

It’s the MT6000 – it supports MID 0008 Tightening Data fine, and the documentation show it supports 0217:

image

Rickedb commented 1 month ago

Could you provide the string of the Mid0008 package that is being sent?

sosborne-control2k commented 1 month ago

Hi,

I have tried many variants:

00640008001 02170013500000000000000000000000000000000000 00640008001 02170013531000000000000000000000000000000000 00320008001 0217 001 03 NUL 00290008001 0217 001 00 006800080010 0217001390 020010020NUL 006800080010 0217001390 020010020

But always get:

002600040010 00 000801

Rickedb commented 1 month ago

To be honest, I've never needed to use Mid0008 since most of common subscriptions mids were enough for me. In your case is Mid0216 that results in receiving Mid0217.

Considering Mid0217, I believe that there is no extra data because it is a common subscription, but your examples without extra data seems to have some spaces between them, which I don't know if it's because of GitHub "spacing fixing" or what you're sending. So just in case, try something like 00290008001 021700100 or 00290008001 021700100NUL (remember that NUL must be the byte 0x00, not the ascii word NUL)

By the way, taking a look at the documentation, it says:

## 3.9.4 Generic Application data subscription
Generic Application data subscriptions is done through MID 0008 and 0009.

Used for ALL possible application data subscriptions they substitutes the following current messages:
MIDs 0014, 0017, 0021, 0024, 0034, 0037, 0051, 0054, 0060, 0063, 0070, 0073, 0090, 0093, 0100, 0103,
0105, 0109, 0120, 0126, 0151, 0154, 0210, 0213, 0216, 0219, 0220, 0223, 0241, 0244, 0250, 0253, 0261,
0264, 0400, 0403, 0420, 0423, 0500, and 0503

All together 40 MID messages.

Have you tried sending 0216 in place of 0217 to see if there is any difference? e.g.: 00290008001 021600100

Rickedb commented 3 weeks ago

Closing due to inactivity, please reopen if necessary.

sosborne-control2k commented 3 weeks ago

Hello, sorry for the delay, found the solution with the help of Atlas Copco last week.

            string extraData = "006"
            var mid0008 = new Mid0008()
            {
                SubscriptionMid = "0217",
                WantedRevision = 1,
                ExtraDataLength = extraData.Length,
                ExtraData = extraData,
            };

Which gives a raw string: 003200080010 021700103006

The extra data is then sepcific to the codes in the following table padded out to three characters:

image image