Hitachi AC Remote (13 Byte, HITACHI_AC1) #1056

soumaxetuirk · 2020-03-05T09:52:04Z

I can receive HITACHI_AC1 codes as the primary support is added for a while now.The AC class is not yet updated to send synthetic commands based on attributes.
I went through previously done work by DiggiD (post #453 )and analysed all other bytes for HITACHI_AC1.
Found: Mode, fan speed, temp, Kaimin (night) mode, Horizontal swing, power,filter rest, timer
The checksum is mostly sum of preceding bytes.(Did not calculate, but seen it changing same value as the other bytes...so)
My IR data spreadsheet.

crankyoldgit · 2020-03-05T10:31:37Z

What is the make and model numbers of both the A/C unit and the IR remote please?

soumaxetuirk · 2020-03-05T10:47:45Z

AC Model: HITACHI KAZE-312KSDP
Remote : R-LT0541-HTA/Y.K.1.1-1 V2.3

crankyoldgit · 2020-03-05T13:21:48Z

@soumaxetuirk Thanks for that.
I think I've worked out code for most of it, but the checksum alg. isn't obvious. You're going to have to work that out in order for it all to work at all.

soumaxetuirk · 2020-03-05T13:26:04Z

@soumaxetuirk Thanks for that.
I think I've worked out code for most of it, but the checksum alg. isn't obvious. You're going to have to work that out in order for it all to work at all.

thank you sir.

@soumaxetuirk

* Add read-only decoding for `HITACHI_AC1` A/C protocol - Power, Fan, Mode, Temp, & Swing * send & write disabled until checksum is figured out. (TODO @soumaxetuirk) * Unit tests for what we can test at present. For #1056

MarkEvens · 2020-03-13T05:27:28Z

when i use example ir receive dump v2 for decode remote it show hitachi ac1 but i don't know how to use is there any example for it

crankyoldgit · 2020-03-13T05:37:18Z

when i use example ir receive dump v2 for decode remote it show hitachi ac1 but i don't know how to use is there any example for it

@MarkEvens Please don't hijack a similar issue for something else. Create your own issue.
There are plenty of examples of how to use things like sendHitachiAc1() in the examples.
e.g. https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRsendDemo/IRsendDemo.ino

DiggiD · 2020-04-01T06:20:14Z

Hiya @crankyoldgit! feels good to reconnect here! havent been able to get into this in a long long long while. Haaa!
have all the time now with the virus lockdowns all over :)

@soumaxetuirk Great stuff!! looks like you got most the functions..
your AC and mine, are off by just 1 bit. should be a physical switch on the backside of your remote in the battery compartment that flips byte 4

yours-->23/Cool/Auto ---- B2AE4D 9 1F061840000000020A8
mine -->23/Cool/Auto ---- B2AE4D 5 1F061840000000020A8

im as flummoxed as yall trying to work out the checksum at the end, but quite looking forward to wrap this up in a neat bow!
found a couple links that i thought might help

https://medium.com/@camilloaddis/smart-air-conditioner-with-raspberry-pi-an-odissey-2a5b438fe984
Camillo has not only decoded his IRP with checksum but also programmed a the encoder-- really illuminating!

https://github.com/hristo-atanasov/Tasmota-IRHVAC
Now this one is my goal, exactly where id like to see this go because im using homeassistant too!
its based on tasmota and David's IRremoteESP8266 library and IRP definitions.

onwards!!!

crankyoldgit · 2020-04-01T06:35:39Z

yours-->23/Cool/Auto ---- B2AE4D 9 1F061840000000020A8
mine -->23/Cool/Auto ---- B2AE4D 5 1F061840000000020A8

What's really interesting is that value change doesn't appear to be affecting the checksum. Bizarre, if correct, that indicates that it's not using every bit/nibble/etc in the checksum alg.

soumaxetuirk · 2020-04-01T08:34:47Z

yours-->23/Cool/Auto ---- B2AE4D 9 1F061840000000020A8
mine -->23/Cool/Auto ---- B2AE4D 5 1F061840000000020A8

On the duster filter command, byte 6 - 12 are zero and the checksum too. I am guessing first 5 bytes are not used for checksum.

@DiggiD I also need the IRHvac with my tasmota. So for now I created a little large csv files with every combination of remote scan code. Then I use a python script to relay required signal by pahomqtt. Its slow but working for the time being .

crankyoldgit · 2020-04-01T08:44:08Z

Okay, that's something to try. Maybe not all of the command is checksum'ed. I'll take a look later.

DiggiD · 2020-04-01T13:09:47Z

What's really interesting is that value change doesn't appear to be affecting the checksum. Bizarre, if correct, that indicates that it's not using every bit/nibble/etc in the checksum alg.

On the duster filter command, byte 6 - 12 are zero and the checksum too. I am guessing first 5 bytes are not used for checksum.

I found this paper setting out to build a universal IRP decoder/encoder, that outlines quite a few methods/algos to work out the checksum- but i haven't worked through all of the algos yet,
@crankyoldgit @soumaxetuirk
do have a look, when you get a chance :)

http://uu.diva-portal.org/smash/get/diva2:910960/FULLTEXT01.pdf
PAGE 13 section 3.2.2

I also need the IRHvac with my tasmota. So for now I created a little large csv files with every combination of remote scan code. Then I use a python script to relay required signal by pahomqtt. Its slow but working for the time being .

this looks like a good workaround! @soumaxetuirk
im using MQTT too, could i look through your implementation perhaps? would be great if i could mcguyver it for my hass instance while we work out the actual IRP :)

crankyoldgit · 2020-04-01T14:55:27Z

I found this paper setting out to build a universal IRP decoder/encoder, that outlines quite a few methods/algos to work out the checksum- but i haven't worked through all of the algos yet,
@crankyoldgit @soumaxetuirk
do have a look, when you get a chance :)

http://uu.diva-portal.org/smash/get/diva2:910960/FULLTEXT01.pdf
PAGE 13 section 3.2.2

I know pretty much everything that paper is talking about (and a heck of a lot more ;-)

Have a read of: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#integrity-checks

I've documented most of the algs I've come across there. I've tried most of them on this one.
It's NOT (just) the common ones, I can assure you. e.g. xor or summing all the data. I didn't try summing only some of the bytes though. (See motivation comments below)

I have read of a checksum alg that sums the lower half of some of the bytes, and xor's the upper half of some of the bytes. I haven't tried that yet, but as I indicate on the site, I've done so many of these now, that I'm weary of doing more. e.g. The Kelvinator one took me weeks to work out, and I did that only because I own one. TL;DR: You've got the motivation to crack it, I don't. ;-)

DiggiD · 2020-04-01T16:02:09Z

I know pretty much everything that paper is talking about (and a heck of a lot more ;-)

:p no doubt no doubt! explains ALL of the nudging im doing 8-]

im no coder, not by a longshot, more like feeling around in the dark learning along the way..
was actually hoping it may spark an idea or two in this discussion. without the help here it would have taken me waay longer than the year ive been banging away at this ONE irp :D heh

Have a read of: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#integrity-checks

on it mate,
cheers!

crankyoldgit · 2020-04-01T16:13:16Z

Most of the checksum algs can be done by hand, or in a spreadsheet. You don't need to be able to program to work it out, but it does help if you can read a program.
Most of them I've done by hand or with a calculator, only using a spreadsheet to organise the data.

DiggiD · 2020-04-01T17:12:52Z

yep, my coding kungfu is limited at best - will come knocking when its time to code it for sure.

Found my IR codes spreadsheet in the wiki.. thanks for that! : )
working to consolidate @soumaxetuirk and my codes into that one sheet- will help later to build an extensive IRP at some point, im hoping.
should be easier to see which bytes are actually affecting the checksum?

camilloaddis · 2020-04-02T00:20:43Z

Hi everybody,
I think I found the algorithm for the checksum calculation, even if I don't know if this is the best way to calculate it.
Let's take this signal string as an example: B2AE4D91F061C8000000001058

The first five bytes (B2AE4D91F0) are ignored as they always remains the same;
each of the next seven bytes is splitted in two groups of four bits (e.g. 0x61, binary 01100001 is splitted into 0110 and 0001);
every group is read as a binary number in reverse – LSB order (e.g. our previous couple becomes 0110 and 1000) ;
all these numbers are summed up to obtain the checksum, also in LSB order (e.g. 61C80000000010 splitted in groups gives 26 as sum, binary 00011010, reversed 01011000 which in hex is 0x58).

Here is the spreadsheet I used to calculate the checksum, based on the data from @soumaxetuirk and @DiggiD spreadsheets, and here's a gist with a simple js function to calculate the checksum with the rest of the string.

Cheers!

crankyoldgit · 2020-04-02T00:57:45Z

@camilloaddis I've tried that, I think. I can't get it to work with all cases.

every group is read as a binary number in reverse – LSB order (e.g. our previous couple becomes 0110 and 1001) ;

Shouldn't that be 0110 and 1000?

crankyoldgit · 2020-04-02T01:14:16Z

Huzzah! .. Yes, it's adding the LSB nibbles(4bits) together after the 5th byte. I'd been trying adding the LSB bytes(8 bits) together.

camilloaddis · 2020-04-02T01:15:43Z

Shouldn't that be 0110 and 1000?

Sure, my bad, only a typo I've just corrected, sorry.

* Add IRac::hitachi1 * Adjust `sendAc()` * Adjust `resultAcToString()` * Add/update unit tests. Fixes #1056 Fixes #1061

@soumaxetuirk

* Add read-only decoding for `HITACHI_AC1` A/C protocol - Power, Fan, Mode, Temp, & Swing * send & write disabled until checksum is figured out. (TODO @soumaxetuirk) * Unit tests for what we can test at present. For #1056

* Add IRac::hitachi1 * Adjust `sendAc()` * Adjust `resultAcToString()` * Add/update unit tests. Fixes #1056 Fixes #1061

crankyoldgit · 2020-04-02T02:28:58Z

@camilloaddis @soumaxetuirk @DiggiD @MarkEvens
I've added the working checksum alg and fully enabled the protocol in this branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/hitachi_ac1_detailed / PR #1072

Please download & try it out and let me know how it goes for you all.

DiggiD · 2020-04-02T23:53:23Z

replaced current IRremote library with https://github.com/crankyoldgit/IRremoteESP8266/tree/hitachi_ac1_detailed
and IRMQTTServer sketch to test.

on the server home page, sending Complex(air conditioner) IR msg works as expected using
HITACHI_AC1 as Type and B2AE4D51F061840000000030B8 as State code

Though constructing a msg on the Air Conditioner Control page of the server does not seem to work
settings used:
Protocol = HITACHI_AC1
Model tried all options in the dropdown i.e. default,unknown,1,2,3,4,5,6
Power = On
Mode = Auto
Temp = 25 C
Fan Speed = Auto
all other options kept off

Q: are the first 5 bits used as constants (since they dont add to the checksum)?
theres a 1 bit difference between my and @soumaxetuirk 's codes and hence possibly not working for me

@soumaxetuirk have you tested it?

soumaxetuirk · 2020-04-03T18:27:31Z

@crankyoldgit I have tested the latest commit.
Only Auto mode is not working.
1-4 bit of 6th byte should be 1110 instead of 1111.

Also thanks @DiggiD, I just marked the restrictions.

Auto mode: TEMP fixed at 25c, FAN fixed at AUTO
Cool mode: NO RESTRICTION
Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO)
Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

About the swing toggle key:
there are 2 bits for swing.in 12th byte the 2nd bit is swing value. and the 8th bit is only swing toggle info. when you change swing value between 0 & 1, only that time 8th bit changes to 1 or else it stays 0.leaving toggle value always 1 is not gonna create any trouble.while the byte is different it provides the same functionality.

soumaxetuirk · 2020-04-03T18:34:16Z

@soumaxetuirk just to double check..
are our remotes exactly the same?!

ive put an image of my remote in the sheet, can you confirm?

the x3C value in Byte 5 points to RESET DUST FILTER for you,
but same value for me gives me a WIDE swing mode (i.e. horizontal vanes move opposite to each other as opposed to together as in H.Swing)

My remote is same as yours except 2 buttons are blank.the lock key & vertical swing. Mine has only vertical swing.I just went through your data sheet.

The 1st bit of 12th byte is SwingH (not yet implemented) & 2nd bit is SwingV. 8th bit is the Swing Toggle.
you are getting issue as in every command SwingH is fixed at 0 for now not for the toggle value.
@crankyoldgit requesting for SwingH implementation (12th byte - 1st bit).

DiggiD · 2020-04-03T18:37:44Z

ive allowed edits temporarily,
ive added your codes table to the sheet as well, could you add your remote's image to the sheet?
https://docs.google.com/spreadsheets/d/1oY_bNaFLmCt-Fu7lKBoQNOIQ1IfCY3-3j6nOzg2e8rQ/edit?usp=sharing

I just went through your data sheet.

do you have a link to share?

you are getting issue as in every command SwingH is fixed at 0 for now not for the toggle value.

yes thats correct

* Remove TODO as data is now fixed. For #1056

Per #1056 (comment)

For: #1056 (comment)

* Use `0bxxxx` notation so I don't make the same mistake for the rest of the modes, Ref: #1056 (comment)

crankyoldgit · 2020-04-04T14:41:42Z

Only Auto mode is not working.
1-4 bit of 6th byte should be 1110 instead of 1111.

Should be fixed now.

requesting for SwingH implementation (12th byte - 1st bit).

Done.

Auto mode: TEMP fixed at 25c, FAN fixed at AUTO
Cool mode: NO RESTRICTION
Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO)
Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

&

Kaimin or Night mode can be activated only on Auto or Cool mode.

I'll try to get to those (restrictions) tomorrow. I'm done for the night!

I've fixed the Sleep/Night values too.

As usual, please download and test, and give feedback etc.

* Sleep mode can be activated only on Auto or Cool mode. * Auto mode: TEMP fixed at 25c, FAN fixed at AUTO * Cool mode: NO RESTRICTION * Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO) * Dry mode: FAN fixed at low * Heat mode : Fan can be High mid or low. (FAN can't be set to AUTO) * Unit tests updated accordingly. Ref: #1056 (comment) & #1056 (comment)

crankyoldgit · 2020-04-04T22:48:58Z

Alright. Restrictions added to the branch. Please test etc.

I think that's the last of it.

soumaxetuirk · 2020-04-05T04:09:23Z

Alright. Restrictions added to the branch. Please test etc.

I think that's the last of it.

thank you @crankyoldgit & @camilloaddis .Everything working ok, I have checked scan codes manually to be sure.
Only one last minor error I found.

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

silly question,
I have seen implementation of On TIMER & OFF timer.if that's true then in which command? what is argument for that?

crankyoldgit · 2020-04-05T06:57:21Z

Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

Geesh! Make up your minds! :-P I'll adapt it soon.

silly question,
I have seen implementation of On TIMER & OFF timer.if that's true then in which command? what is argument for that?

See:
ae11fc4#diff-cd4d85e9786ca64a0f3a8926ecc5293bR223-R226
& ae11fc4#diff-d5d6db27d28df393499227716fa26edbR1612-R1618

i.e.

  ac.setOnTimer(2 * 60 + 39);  // 2h39m, 0 is off
  ac.setOffTimer(10 * 60 + 17);  // 10h17m, 0 is off

soumaxetuirk · 2020-04-05T07:17:32Z

Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

Geesh! Make up your minds! :-P I'll adapt it soon.

silly question,
I have seen implementation of On TIMER & OFF timer.if that's true then in which command? what is argument for that?

See:
ae11fc4#diff-cd4d85e9786ca64a0f3a8926ecc5293bR223-R226
& ae11fc4#diff-d5d6db27d28df393499227716fa26edbR1612-R1618

i.e.
  ac.setOnTimer(2 * 60 + 39);  // 2h39m, 0 is off
  ac.setOffTimer(10 * 60 + 17);  // 10h17m, 0 is off

I mean current commit restricting to wrong fan mode.
As I said before DRY mode should have FAN fixed at low. That is correct information.

But in the latest commit,IRRemoteESP8266 is restricting it to AUTO.

@soumaxetuirk

* According to @soumaxetuirk : "In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only." For: #1056 (comment)

crankyoldgit · 2020-04-05T07:19:39Z

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

@soumaxetuirk done

crankyoldgit · 2020-04-05T07:23:51Z

I mean current commit restricting to wrong fan mode.
As I said before DRY mode should have FAN fixed at low. That is correct information.

@soumaxetuirk Wait?! What now? I'm utterly confused.

Are these statement(s) correct?

Auto mode: TEMP fixed at 25c, FAN fixed at AUTO
Cool mode: NO RESTRICTION
Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO)
Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)
&
Kaimin or Night mode can be activated only on Auto or Cool mode.

If so, then the change I've just made will screw that up.
Also "If so", then what was it doing wrong, and how did you get it to go "wrong" i.e. what sequence etc?

It appears there is a communcation problem See: #1056 (comment) & #1056 (comment)

soumaxetuirk · 2020-04-05T07:30:10Z

The statement I provided at beginning is correct. But your previous commit was restricting FAN to AUTO. (In dry mode)
So I asked to fix it as per I mentioned at first.
Sorry for my English.

crankyoldgit · 2020-04-05T07:31:51Z

So it's back to the way it was (after my "fix").
How did you get it to the wrong speeds? What method are you using to control it? what sequence?

soumaxetuirk · 2020-04-05T07:47:58Z

IRSend:
IRhvac {"Vendor":"HITACHI_AC1", "Power":"On","Mode":"dry","FanSpeed":"low","Temp":22.5}
IRReceived:
B2AE4D91F021F800000000310C

Which means 6th Byte is 0010001.It should be 00101000.

Also all these restrictions are build to remote.If I send wrong combination then AC accepts it and also shows on display too.But FAN rotates slow only.

* Added more unit tests to check/confirm it now works. Ref: #1056 (comment)

crankyoldgit · 2020-04-05T08:22:59Z

@soumaxetuirk Dry mode fan is now fixed to low. Please check etc. Anything else?

soumaxetuirk · 2020-04-05T08:46:46Z

All done! Thank you 😊

DiggiD · 2020-04-05T11:33:44Z

double checked!! everything is working beautifully as expected !!

thank you @crankyoldgit @soumaxetuirk @camilloaddis

@camilloaddis

* Add settings for `HITACHI_AC1` A/C protocol - Power, Fan, Mode, Temp, Swing, Sleep, On & Off Timers. - Kudos to @camilloaddis for working out the alg, & @soumaxetuirk for reverse engineering settings. * Add support for it in the Common A/C api * Add unit tests. Fixes #1056 Fixes #1061

_v2.7.5 (20200409)_ **[Features]** - Detailed support for `HITACHI_AC1` protocol. (#1056, #1061, #1072) - update sharp to match Sharp AH-A5SAY (#1074) - Experimental support for AIRWELL protocol. (#1069, #1070) - SamsungAC: Add Breeze (Aka WindFree) control (#1062, #1071) - Support for Daikin FFN-C A/C (#1064, #1065) - Add basic support for HITACHI_AC3 protocol. (#1060, #1063) - Add support for `SYMPHONY` 11 bit protocol. (#1057, #1058) - IRMQTTServer: Improve Home-Assistant discovery by sending a 'device' with the discovery packet (#1055) **[Misc]** - Clean up support status of various protocols. - Add `decodeToState()` unit tests to all supported protocols (#1067, #1068) - Add Gree AC example code. (#1066)

crankyoldgit · 2020-04-09T06:29:07Z

FYI, This has been included in the new v2.7.5 release of the library.

crankyoldgit self-assigned this Mar 5, 2020

crankyoldgit added the enhancement label Mar 5, 2020

crankyoldgit added the more info label Mar 5, 2020

crankyoldgit mentioned this issue Mar 13, 2020

I write program using ir_Hitachi liberary but it is not working #1061

Closed

crankyoldgit added a commit that referenced this issue Apr 2, 2020

Add HITACHI_AC1 to Common A/C api.

b44de67

* Add IRac::hitachi1 * Adjust `sendAc()` * Adjust `resultAcToString()` * Add/update unit tests. Fixes #1056 Fixes #1061

crankyoldgit added a commit that referenced this issue Apr 2, 2020

Add HITACHI_AC1 to Common A/C api.

6f9f93f

* Add IRac::hitachi1 * Adjust `sendAc()` * Adjust `resultAcToString()` * Add/update unit tests. Fixes #1056 Fixes #1061

crankyoldgit mentioned this issue Apr 2, 2020

Detailed support for HITACHI_AC1 protocol. #1072

Merged

crankyoldgit added a commit that referenced this issue Apr 4, 2020

Improve IRHitachiAc1's sleep settings.

30223d3

* Remove TODO as data is now fixed. For #1056

crankyoldgit added a commit that referenced this issue Apr 4, 2020

Make Sleep mode 2 the default for Common API

7af6755

Per #1056 (comment)

crankyoldgit added a commit that referenced this issue Apr 4, 2020

IRHitachiAc1: Add support for SwingH

2febeb8

For: #1056 (comment)

crankyoldgit added a commit that referenced this issue Apr 4, 2020

Fix typo/bit-math-fail in kHitachiAc1Auto value.

9ff836d

* Use `0bxxxx` notation so I don't make the same mistake for the rest of the modes, Ref: #1056 (comment)

crankyoldgit added a commit that referenced this issue Apr 5, 2020

Change Dry and Heat fan speeds.

f8de5ce

* According to @soumaxetuirk : "In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only." For: #1056 (comment)

crankyoldgit added a commit that referenced this issue Apr 5, 2020

Revert last commit.

7781e04

It appears there is a communcation problem See: #1056 (comment) & #1056 (comment)

crankyoldgit added a commit that referenced this issue Apr 5, 2020

Lock fan speed to Low in Dry mode.

5dfdfa1

* Added more unit tests to check/confirm it now works. Ref: #1056 (comment)

crankyoldgit closed this as completed in #1072 Apr 9, 2020

crankyoldgit mentioned this issue Apr 9, 2020

v2.7.5 Release #1077

Merged

Hitachi AC Remote (13 Byte, HITACHI_AC1) #1056

Hitachi AC Remote (13 Byte, HITACHI_AC1) #1056

Comments

soumaxetuirk commented Mar 5, 2020

crankyoldgit commented Mar 5, 2020

soumaxetuirk commented Mar 5, 2020

crankyoldgit commented Mar 5, 2020

soumaxetuirk commented Mar 5, 2020

MarkEvens commented Mar 13, 2020

crankyoldgit commented Mar 13, 2020

DiggiD commented Apr 1, 2020 • edited Loading

crankyoldgit commented Apr 1, 2020

soumaxetuirk commented Apr 1, 2020

crankyoldgit commented Apr 1, 2020

DiggiD commented Apr 1, 2020 • edited Loading

crankyoldgit commented Apr 1, 2020

DiggiD commented Apr 1, 2020

crankyoldgit commented Apr 1, 2020

DiggiD commented Apr 1, 2020

camilloaddis commented Apr 2, 2020 • edited Loading

crankyoldgit commented Apr 2, 2020

crankyoldgit commented Apr 2, 2020

camilloaddis commented Apr 2, 2020

crankyoldgit commented Apr 2, 2020

DiggiD commented Apr 2, 2020 • edited Loading

soumaxetuirk commented Apr 3, 2020 • edited Loading

soumaxetuirk commented Apr 3, 2020 • edited Loading

DiggiD commented Apr 3, 2020 • edited Loading

crankyoldgit commented Apr 4, 2020

crankyoldgit commented Apr 4, 2020

soumaxetuirk commented Apr 5, 2020

crankyoldgit commented Apr 5, 2020

soumaxetuirk commented Apr 5, 2020

crankyoldgit commented Apr 5, 2020

crankyoldgit commented Apr 5, 2020

soumaxetuirk commented Apr 5, 2020

crankyoldgit commented Apr 5, 2020

soumaxetuirk commented Apr 5, 2020

crankyoldgit commented Apr 5, 2020

soumaxetuirk commented Apr 5, 2020

DiggiD commented Apr 5, 2020 • edited Loading

crankyoldgit commented Apr 9, 2020

DiggiD commented Apr 1, 2020 •

edited

Loading

DiggiD commented Apr 1, 2020 •

edited

Loading

camilloaddis commented Apr 2, 2020 •

edited

Loading

DiggiD commented Apr 2, 2020 •

edited

Loading

soumaxetuirk commented Apr 3, 2020 •

edited

Loading

soumaxetuirk commented Apr 3, 2020 •

edited

Loading

DiggiD commented Apr 3, 2020 •

edited

Loading

DiggiD commented Apr 5, 2020 •

edited

Loading