How to connect via Modbus (RS485) a Samsung HVAC external unit with MIM-B19N

pedrolima · October 20, 2022, 11:04pm

Hey Rossko, I don’t want to abuse your simpathy in helping, but I do need your help!

So, I installed this software, connected the USB pen to my laptop and tested it. It just works! I can read and write commands.

Here are the configs that worked out:

In this example I deactivated a specific unit and activated:

But I keep not knowing what I am doing wrong in OH because I’ve messed with settings and I just can’t write nor read anything.

Can you shed some light on this?

Thanks a lot in advance!

rossko57 · October 23, 2022, 2:34pm

Can’t see what you have done, nor what happens or does not happen as a result.
Start simple; choose an example of

to reproduce in your openHAB settings.

Reminder, if your mbpoll software is using the serial port, then openHAB cannot.

pedrolima · October 23, 2022, 3:15pm

First, thank you for your help!

My settings are right now basically the same as I had when I started this topic.

I tried to reproduce all settings in OH and I simply can’t make it work.

I used a PC with Windows and connected the USB stick there, so it has nothing to do with my Raspberry Pi where I have OH installed.

I am really stuck without knowing what should I try next because it feels that I’ve tried “everything” (but obviously haven’t, otherwise I would have already made it).

So, these are my settings right now:

And although everything says always “Online”, nothing seems to communicate. I don’t even have any info in my logs.

rossko57 · October 23, 2022, 6:08pm

Serial Bridge Thing -
If you’re using a USB-RS485 adaptor, I think it is usual to specify flow control = none

Modbus Poller Thing -
length = 125 is a bit excessive if you’re only going to look at two or three registers. Try just 10 or something for now.

I’ve no idea if you actually wanted to read holding register 0, the previous screenshots of MBpoll do not show a working read to compare.
The log snippet shows a request to read ten holding registers, starting at address 0.
That request is rejected with an exception code 02, i.e. illegal address.
So I would expect your openHAB setup to fail in the same way.

Because you’ve got a rejection, and not just silence, at least you know you are talking to a valid device ID

Once again, maybe you can show us the MBpoll setup that you say worked?

pedrolima · October 24, 2022, 12:54am

If I do this, in my modbus poll this message appears: Error with read: org.openhab.core.io.transport.modbus.internal.ModbusSlaveIOExceptionImpl: Modbus IO Error with cause=ModbusIOException, EOF=false, message=‘I/O failed to write’, cause2=null

So does this mean that this is the “ID” of each modbus unit on each external AC unit? There are 5 external units by the way.

And then, how can I send 1 and 0 (ON and OFF) to the internal “ID” 52 (to activate this wall control inside a specific room)?

I have no idea if the “read” worked, but I am sure the “write” did worked, I saw it turning ON and OFF.

The only setup I did in that Windows software was those 2 screenshots I sent you, that’s it. I did no other settings.

rossko57 · October 24, 2022, 1:35am

No idea. From memory, the “modbus box” maps the various internal units to different register ranges derived from base ID, and exposes these on its external modbus all on one ID.

There’s really no point even trying to read with openHAB until/unless you can get a read with mbpoll. You will not stumble on it at random. Let’s abandon that for now.

No idea, see above.

But if you want to emulate the mbpoll write, we can do that. openHAB Modbus binding allows you to configure write-only Data Things as direct children of a Serial bridge Thing. No poller required, as no read required for write only.

Your existing Serial bridge Thing appears reasonable.

So to replicate the mbpoll write shown, create a new data Thing as child of serial Thing, no read paramaters, write start address 52, write type holding, write single register. (The Serial Thing has the ID=1 part of the config)
Link this data Thing’s number channel to a Number type Item, command this Item with “0”.

pedrolima · October 24, 2022, 2:07am

Here, what should I put in my “Write Value Type”? I’ve tried many but the internal unit never turns the AC of that room “ON” and besides, the “Last Successful Write” and “Last Erroring Write” still have “null” on both.

I’ve created a basic rule to set the “Value as Number” to 1 each 10 seconds, so I could be changing settings and see if the internal unit would turn on at any time.

So, no luck so far…

Wasn’t modbus suposed to be simple? I’ve just struggled so much with this, it’s crazy! And the amount of money burned already in “modbus” interfaces for the AC units, it’s also ridiculous, so there is no way back now, I need to put this working… somehow

rossko57 · October 24, 2022, 12:09pm

To replicate your mbpoll single register write of a standard 16-bit holding register, you would want int16 (for 16-bit integer)

If you want something to happen on Modbus, you must send a command to the linked Item. Setting the Item state will not do, This is fairly key understanding to doing anything with openHAB att all.

Modbus itself is idiotically simple. That means that we, the users, have to supply the knowledge in detail. Unfortunately in this case you don’t know what it is you are trying to do to your target device in Modbus terms.

pedrolima · October 24, 2022, 2:09pm

Yup, tried that option.

Yup, this was the rule I created as I said:

rule "Test modbus"

when
   Time cron "*/10 * * * * ? *"
then
   ModbusData_ValueasNumber.sendCommand(1)
end

Exactly!

rossko57 · October 24, 2022, 2:57pm

And? What would you like to happen now? Please remember we just cannot see what you are looking at, what you are doing, what you think is supposed to happen, what actually happens, etc etc.

Alright, is that an Item we have not heard about before?
Does it get a command - see your events.log. Especially, share your events.log.
Does it have some relationship to your Modbus config? Again, share. Use ,code. tabs when possible, preferred over screenshots.

pedrolima · October 24, 2022, 3:11pm

I know, and that’s why I have even more consideration for all your patience with cases like this!

It’s literally the item I mention right here.

Yes it does, here you go some examples:

2022-10-24 15:26:40.615 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 15:26:40.621 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1
2022-10-24 15:26:50.614 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 15:26:50.616 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1
2022-10-24 15:27:00.612 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 15:27:00.615 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1
2022-10-24 15:27:10.615 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 15:27:10.618 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1
2022-10-24 15:27:20.616 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 15:27:20.620 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1
2022-10-24 15:27:30.616 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 15:27:30.620 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1

Yup, shown above.

Ok, will do that in the future. Thanks!

rossko57 · October 24, 2022, 5:59pm

How convinced are you that you are supposed to be writing ‘1’ to this register? The only mbpoll example that you say did something, wrote 0.

Sure, but on that screenshot I cannot make out what Thing this Item is linked to, nor of course how that Thing itself is configured.

We’re looking at a chain of stuff here, if you wiggle one end of the chain and it doesn’t do what you think, you need to examine every link in the chain.

This sort of thing worries me. Okay, you tried this and that - but how is it left now? It’s not clear.
And as I keep on, you won’t get this working by random fiddling. If unknown what to do, let’s work it out.
Note that cycling through random settings is likely to mess it up, for various technical reasons - “old” settings can persist and cause you problems masking settings that could be correct now. Stop, go slow.

All you want at this stage -
A Modbus Serial Bridge Thing
A Data Thing, a direct child of the serial bridge, with write settings only.
An Item, linked to the Data Thing.
When you’ve got everything how you want it, restart the binding for a fresh beginning. If you don’t know how, restart openHAB.
Look at your openhab.log for Modbus binding initializing.
Send your Item a command.
Look at your openhab.log for complaints.

I’m not very convinced that you are looking out for openhab.log entries relating to Modbus either?

pedrolima · October 24, 2022, 8:18pm

I’m 100% sure because I tried with 1 as well, to turn it ON and it did, but I took the screenshot when I sent 0 to turn it OFF, which it did as well.

To make it easier, here are the codes instead of screenshots:

UID: modbus:serial:modbus
label: Modbus Serial Slave 01
thingTypeUID: modbus:serial
configuration:
  baud: 9600
  connectMaxTries: 3
  timeBetweenTransactionsMillis: 35
  stopBits: "1.0"
  parity: even
  receiveTimeoutMillis: 1500
  dataBits: 8
  echo: true
  encoding: rtu
  flowControlIn: rts/cts in
  flowControlOut: rts/cts out
  port: /dev/ttyRS485
  connectTimeoutMillis: 10000
  afterConnectionDelayMillis: 0
  id: 1
  enableDiscovery: true

UID: modbus:poller:modbus:modbuspoll
label: Modbus Poll
thingTypeUID: modbus:poller
configuration:
  length: 5
  start: 0
  refresh: 500
  maxTries: 3
  cacheMillis: 50
  type: holding
bridgeUID: modbus:serial:modbus

UID: modbus:data:modbus:modbusdata
label: Modbus Data
thingTypeUID: modbus:data
configuration:
  readTransform: default
  writeTransform: default
  writeType: holding
  updateUnchangedValuesEveryMillis: 1000
  writeValueType: int16
  writeMultipleEvenWithSingleRegisterOrCoil: false
  writeMaxTries: 3
  writeStart: "52"
bridgeUID: modbus:poller:modbus:modbuspoll

Ok, this I had no idea that it could happen!

So let’s go step-by-step on the things you mentioned:

A Modbus Serial Bridge Thing - CHECK
(here I need in between these two, a Modbus Poll, right?)
A Data Thing, a direct child of the serial bridge, with write settings only. - CHECK
An Item, linked to the Data Thing. - CHECK
When you’ve got everything how you want it, restart the binding for a fresh beginning. If you don’t know how, restart openHAB. - CHECK
Look at your openhab.log for Modbus binding initializing. - CHECK
I suppose you are refering to this: 2022-10-24 19:26:31.845 [INFO ] [rt.modbus.internal.ModbusManagerImpl] - Modbus manager activated
Send your Item a command. - CHECK
Accomplished with that rule running each 10secs
Look at your openhab.log for complaints. - CHECK
Zero complains while running the rule, only the events.log with the information I mentioned before, like this:

2022-10-24 21:14:01.801 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 21:14:01.812 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1
2022-10-24 21:14:10.698 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusData_ValueasNumber' received command 1
2022-10-24 21:14:10.706 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusData_ValueasNumber' predicted to become 1

So that’s it.

What more can I tell you in order to help you, helping me?

And, once again, I thank you so much Rossko!

rossko57 · October 25, 2022, 1:09am

No.

Here we make a purely write-only data Thing to exactly emulate the mbpoll that you say worked. The idea is to make one simple function work. If you can’t achieve that, there is no point continuing.

There is no point even considering how to set up openHAB for reading until you have had a succesful reading using mbpoll, which has not been achieved yet (unless we have not been told about that either)

(poller Thing are about polling, reading, not required for writing,)

So you’ve gone wrong at step 2.
Make a new data Thing for write-only, make it a direct child of the serial bridge, link a new Item to that, send it a command.

pedrolima · October 25, 2022, 2:09am

First of all, you are the man!

It finally worked BUT, it worked because I changed the flow for “none”, just like you mentioned already in the past, instead of having it as RTS.

Ok, so here’s the data Thing created as you suggested:

UID: modbus:data:modbus:c6888da8f6
label: Modbus Data write-only
thingTypeUID: modbus:data
configuration:
  readTransform: default
  writeType: holding
  writeTransform: default
  updateUnchangedValuesEveryMillis: 1000
  writeValueType: int16
  writeMultipleEvenWithSingleRegisterOrCoil: false
  writeMaxTries: 3
  writeStart: "52"
bridgeUID: modbus:serial:modbus

I did created a new Item to test this and changed the rule to sendCommand(1) to the channel “Value as Number” and that’s what worked out.

BUT… now a curious thing! In the “Last Successful Write” item I still have “NULL” and on the “Last Erroring Write” I do have now a timestamp.

Although I am not in that house, I do see in one of the interior cameras the wall device that did turned ON and OFF.

Here it is turned ON:

And here’s again, but OFF:

So yeah, it works.

The weird thing is, I get this error message in my new data Thing:

Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null

But at least I can already send commands, which is actually very nice already!

And here’s the openhab.log:

2022-10-25 03:11:22.443 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID 838bf5d1-6cd8-4b2a-843f-e6423628fdb1]
2022-10-25 03:11:24.020 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID 838bf5d1-6cd8-4b2a-843f-e6423628fdb1]
2022-10-25 03:11:25.601 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Aborting. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID 838bf5d1-6cd8-4b2a-843f-e6423628fdb1]
2022-10-25 03:11:27.222 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=0, length=5, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O failed to write [operation ID aed49561-3890-433e-81e7-d9d9ba7b4367]
2022-10-25 03:11:28.822 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=0, length=5, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O failed to write [operation ID aed49561-3890-433e-81e7-d9d9ba7b4367]
2022-10-25 03:11:30.422 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=0, length=5, maxTries=3]). Aborting. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O failed to write [operation ID aed49561-3890-433e-81e7-d9d9ba7b4367]
2022-10-25 03:11:32.434 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID e3250636-ef89-4686-ab66-d9c94a160706]
2022-10-25 03:11:34.017 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID e3250636-ef89-4686-ab66-d9c94a160706]
2022-10-25 03:11:35.600 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Aborting. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID e3250636-ef89-4686-ab66-d9c94a160706]
2022-10-25 03:11:37.221 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=0, length=5, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O failed to write [operation ID 99f1b56b-4cb6-4433-98af-0f318113e6c0]

And here the events.log:

2022-10-25 03:13:15.611 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ModbusDatawriteonly_LastErroringWrite' changed from 2022-10-25T03:13:05.606360+0100 to 2022-10-25T03:13:15.604937+0100
2022-10-25 03:13:20.876 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusDatawriteonly_ValueasNumber' received command 0
2022-10-25 03:13:20.881 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusDatawriteonly_ValueasNumber' predicted to become 1
2022-10-25 03:13:25.619 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ModbusDatawriteonly_LastErroringWrite' changed from 2022-10-25T03:13:15.604937+0100 to 2022-10-25T03:13:25.604097+0100
2022-10-25 03:13:30.874 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ModbusDatawriteonly_ValueasNumber' received command 0
2022-10-25 03:13:30.877 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ModbusDatawriteonly_ValueasNumber' predicted to become 1

rossko57 · October 25, 2022, 10:33pm

pedrolima:

Try 1 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=52, ...
Try 2 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint ...
Last try 3 failed when executing request (ModbusWriteRegisterRequestBlueprint ...

Okeydoke.
openHAB thinks every write attempt is failing.

Great, the message got there …
So that implies our command arrives at the target, hurrah - but no response is received at openHAB. (Modbus protocol requires a slave to acknowledge a successful write.)

At this point, I would suggest returning to mbpoll anbd test your write action, but this time check to see if there is an acknowledgement. (The little hex comms log in the earlier screenshot did not include the write tx/rx)

There could be a reading problem (maybe even flow control) or the Samsung may not be playing by the rules. Let’s find out.

pedrolima · October 25, 2022, 11:13pm

Isn’t this “Response ok” what we need?

I mean, at a certain point I checked that checkbox and it did closed the window after a write. So I assume this means that the result was “Response ok”.

I will actually be able to test again the Mbpoll tomorrow, so if you have any other ideas for me to test, just let me know and I can do that.

I also find strange the fact that every Tx gets error:

At least I’m already “half-happy” because being able to control each unit is already an achievement.

rossko57 · October 26, 2022, 12:44am

I don’t know. I want to see the full hex query / response messages for the write. The mbpoll screenshot shows only the periodic query/response for the read (which is having an error).

I think the counter you are looking at there is for mbpolls auto read polls.
Remember this is a master - slave protocol.
openHAB or mbpoll are master.
Slaves do not speak until spoken to.
Thus a “read” or a “write” to a slave register will both always comprise of a tx + rx transaction, a query from master and a response from slave. The data just takes different forms for “read” and “write”.

We’ve already seen that the slave is simply rejecting each mbpoll read you had set up previously, so seeing an error for every poll is unsuprising.
It might be more interesting if it said Tx count 850 Err count 849 after you had sent a “write”.

If you want to try something else, set up mbpoll to read poll holding registers 50 (decimal) to count 32

pedrolima · October 26, 2022, 1:48am

I see, in a few more hours I will be able to use again Mbpoll software to test this directly on my PC.

In the meanwhile, I did changed on the “Modbus Poll” Thing, the “Start” to 50 and “Lenght” to 32 (was this what you were talking about?) and it did changed the error message, now I get this one:

Error with read: org.openhab.core.io.transport.modbus.internal.ModbusSlaveIOExceptionImpl: Modbus IO Error with cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 00 00 ', cause2=null

pedrolima · October 26, 2022, 10:28am

Here’s a bit of the log that appears on the Mbpoll software, the first one is when I sent 1 to activate the address 52 and the second one that appears is when I sent 0:

Tx:000178-01 03 00 00 00 0A C5 CD
Rx:000179-01 83 02 C0 F1
Tx:000180-01 03 00 00 00 0A C5 CD
Rx:000181-01 83 02 C0 F1
Tx:000182-01 03 00 00 00 0A C5 CD
Rx:000183-01 83 02 C0 F1
Tx:000184-01 06 00 34 00 01 09 C4
Rx:000185-01 06 00 34 00 01 09 C4
Tx:000186-01 03 00 00 00 0A C5 CD
Rx:000187-01 83 02 C0 F1
Tx:000188-01 03 00 00 00 0A C5 CD
Rx:000189-01 83 02 C0 F1
Tx:000190-01 03 00 00 00 0A C5 CD
Rx:000191-01 83 02 C0 F1
Tx:000192-01 06 00 34 00 00 C8 04
Rx:000193-01 06 00 34 00 00 C8 04
Tx:000194-01 03 00 00 00 0A C5 CD
Rx:000195-01 83 02 C0 F1
Tx:000196-01 03 00 00 00 0A C5 CD
Rx:000197-01 83 02 C0 F1
Tx:000198-01 03 00 00 00 0A C5 CD
Rx:000199-01 83 02 C0 F1

And here’s a screenshot: