values for GW5000S-BP don't seem to match up about goodwe

[craigcurtin-dev]

Have a look at the work i did on the Goodwe SBP5000 and the breakdown of the responses etc - there is a long series of posts on the Australian Whirlpool discussion forums in the energy section about Grid Arbitrage.

I also put a lot of debugging stuff i worked through in the issues of this Github repository

mletenay/home-assistant-goodwe-inverter#48

Craig

[oziee]

thanks Craig..

I had found that thread and read through before. its just a pity that values do not link to what they mean. I would have expected PV values to be empty since there is no PV connections.

im still trying to work out which sensor items to tally to work out solar production etc since there is a CT clamp there must be some type of sensor to work with

[craigcurtin-dev]

Did you have a look at the Whirlpool thread on Grid Arbitrage ? There are a couple of guys who are using Modbus on ESP devices to talk to the inverter and pull out stats and control the battery (which one day i will probably get around to as well !)

I think you might find that the SBP5000 shares the same registers with the 5048 series - that do support Solar Panels.

Craig

[craigcurtin-dev]

I think you will need to pick apart their Python code and see which registers they are mapping - i think they are lumping the SBP in with the 5048 series and assuming the results are the same (as very few people have these inverters) and hence they are mapping some info incorrectly.

Do you have the GM1000D (dual CT clamp sensor with yours) or the GM3000 (3 Phase ?)

Craig

[oziee]

GM1000D

Forking and hacking it is :)

[craigcurtin-dev]

Did you see the one where I list the registers/packets for the gm1000d on the whirlpool thread ?? Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Greg ***@***.***> Sent: Thursday, July 21, 2022 9:36:19 AM To: marcelblijleven/goodwe ***@***.***> Cc: Craig Curtin ***@***.***>; Comment ***@***.***> Subject: Re: [marcelblijleven/goodwe] values for GW5000S-BP don't seem to match up (Issue #20) GM1000D Forking and hacking it is :) — Reply to this email directly, view it on GitHub<#20 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6OSTZFVAT6CHXYYCV6SLDVVCEPHANCNFSM53R4O2VA>. You are receiving this because you commented.Message ID: ***@***.***>

[oziee]

@craigcurtin-dev yup.. been reading though whirlpool too..

also reverse engineering the PV Master app.. seem that the SBP might be a different type than what it is selected in code in this repo.. might be EH type

public static int getEHBHSBType() {
        byte var0;
        if (Constant.Inverter_sn.contains("5000")) {
            var0 = 1;

public static boolean is105PlatForm() {
        return Constant.Inverter_sn.contains("ESU") || Constant.Inverter_sn.contains("EMU") || Constant.Inverter_sn.contains("ESA") || Constant.Inverter_sn.contains("BPS") || Constant.Inverter_sn.contains("BPU");
    }

[craigcurtin-dev]

Pretty sure it does not identify as an EH as I think that is one of their 3 phase newer units – but maybe you are right there and that is the missing piece – I know that it does not respond to Modbus over WIFI/LAN though and pretty sure the EH does ? Craig From: Greg ***@***.***> Sent: Thursday, July 21, 2022 8:07 PM To: marcelblijleven/goodwe ***@***.***> Cc: Craig Curtin ***@***.***>; Mention ***@***.***> Subject: Re: [marcelblijleven/goodwe] values for GW5000S-BP don't seem to match up (Issue #20) @craigcurtin-dev<https://github.com/craigcurtin-dev> yup.. been reading though whirlpool too.. also reverse engineering the PV Master app.. seem that the SBP might be a different type than what it is selected in code in this repo.. might be EH type public static int getEHBHSBType() { byte var0; if (Constant.Inverter_sn.contains("5000")) { var0 = 1; public static boolean is105PlatForm() { return Constant.Inverter_sn.contains("ESU") || Constant.Inverter_sn.contains("EMU") || Constant.Inverter_sn.contains("ESA") || Constant.Inverter_sn.contains("BPS") || Constant.Inverter_sn.contains("BPU"); } — Reply to this email directly, view it on GitHub<#20 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6OST2364PIRNGMJTTFZQ3VVEONPANCNFSM53R4O2VA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[Uksa007]

@marcelblijleven I have the same issues with same inverter, how can we progess resolution, happy to help.
home-assistant/core#79866

[lyricnz]

@Uksa007 (as commented in the other issue) please provide output from the following program (change the ip_address to yours), plus a capture of matching data from semsportal so they can be compared/aligned.

import asyncio
import goodwe
import logging

async def get_runtime_data():
    ip_address = '192.168.30.126'

    inverter = await goodwe.connect(ip_address)
    runtime_data = await inverter.read_runtime_data(include_unknown_sensors=True)

    for sensor in inverter.sensors():
        if sensor.id_ in runtime_data:
            print(f"{sensor.id_}: \t\t {sensor.name} = {runtime_data[sensor.id_]} {sensor.unit}")


logging.basicConfig(level=logging.DEBUG)
asyncio.run(get_runtime_data())

[Uksa007]

@lyricnz @oziee has provided the same info that i can post at top of this issue, I don't see the point in duplicating.
We need some direction from @marcelblijleven as to how to resolve.

[lyricnz]

@Uksa007 when you run with the debug flag turned on, the raw bytes from the inverter are displayed, not just the "processed" key-value. The problem is (I'm assuming) in the interpretation of the bytes, so looking at the known-bad data isn't so helpful.

For example, mine is:

DEBUG:goodwe:Connecting to DT family inverter at 192.168.30.126.
DEBUG:goodwe.inverter:Creating lock instance for current event loop.
DEBUG:goodwe.protocol:Sending: 7f03753100280409
DEBUG:goodwe.protocol:Received: aa557f0350000200c80001303030304B4454413030303030303030475732304b41552d4454ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000f000f0010044b00bb00030000e4bd
DEBUG:goodwe:Connected to inverter GW20KAU-DT, S/N:xxx.
DEBUG:goodwe.protocol:Sending: 7f0375940049d5c2
DEBUG:goodwe.protocol:Received: aa557f0392160a1513172a0f4100440dbc0047ffffffffffffffffffffffffffffffff0f2d0f4d0f6908d508bc08eb0048004a00471384138413850000135d000100000000000000000000000000cd0000000003e7ffff016cffffffff00c60000a8280000047300200000000000000000ffffffffffffffffffffffffffffffff0000174b0bad000000040000044b00000004000000696b04

With your inverter bytes, we can create a test-case (like this) using it, then iterate on the interpretation until it matches what you know from semsportal.

[Uksa007]

@lyricnz it seems to identify as BP inverter which it is.

I will try to get matching data with SEMS but it is always behind and think it may do some averaging, as it's update is slow.
Edit: updated with matching data from SEMS

DEBUG:asyncio:Using proactor: IocpProactor
DEBUG:goodwe:Connecting to BP family inverter at 192.168.60.134.
DEBUG:goodwe.inverter:Creating lock instance for current event loop.
DEBUG:goodwe.protocol:Sending: aa55c07f0102000241
DEBUG:goodwe.protocol:Response has unexpected length: 149, expected 149.
DEBUG:goodwe.protocol:Received invalid response: aa557fc001868c0ec5000c000000000100020f019f0050010400360064006400001c001c6403000001097800180001138b0100000016ff02138d00020160000000000000048e0000016d0011003d00000f75ff0201003000000000010000febf100008000000160a160d0e25000000000000000000000000000000000000000000000000000004e7000004bf020000000000001128
DEBUG:goodwe.protocol:Sending: aa55c07f0102000241 - retry #1/3
DEBUG:goodwe.protocol:Received: aa557fc001824d3130313043475735303030532d42502331300000000000000000000000000039353030304250533232335730313336333630303431302d30343030312d3130093431302d30323033342d313502100e
DEBUG:goodwe:Connected to inverter GW5000S-BP, S/N:removed.
DEBUG:goodwe.protocol:Sending: aa55c07f0106000245
DEBUG:goodwe.protocol:Failed to receive response to aa55c07f0106000245 in time (1s).
DEBUG:goodwe.protocol:Sending: aa55c07f0106000245 - retry #1/3
DEBUG:goodwe.protocol:Received: aa557fc001868c0ebb000d000000000100020f019f0050010400360064006400001c001c640300000109760019000e13890100000017ff02138900020160000000000000048e0000016d0011003d00000f75ff0201003000000000010000fec1100008000000160a160d0e25000000000000000000000000000000000000000000000000000004e7000004bf020000000000001128
vpv1:            PV1 Voltage = 377.1 V
ipv1:            PV1 Current = 1.3 A
ppv1:            PV1 Power = 490 W
pv1_mode:                PV1 Mode code = 0
pv1_mode_label:                  PV1 Mode = PV panels not connected
vpv2:            PV2 Voltage = 0.0 V
ipv2:            PV2 Current = 0.1 A
ppv2:            PV2 Power = 0 W
pv2_mode:                PV2 Mode code = 0
pv2_mode_label:                  PV2 Mode = PV panels not connected
ppv:             PV Power = 490 W
vbattery1:               Battery Voltage = 52.7 V
battery_status:                  Battery Status = 80
battery_temperature:             Battery Temperature = 26.0 C
ibattery1:               Battery Current = -5.4 A
pbattery1:               Battery Power = -285 W
battery_charge_limit:            Battery Charge Limit = 100 A
battery_discharge_limit:                 Battery Discharge Limit = 100 A
battery_error:           Battery Error Code = 0
battery_soc:             Battery State of Charge = 28 %
battery_soh:             Battery State of Health = 100 %
battery_mode:            Battery Mode code = 3
battery_mode_label:              Battery Mode = Charge
battery_warning:                 Battery Warning = 0
meter_status:            Meter Status code = 1
vgrid:           On-grid Voltage = 242.2 V
igrid:           On-grid Current = 2.5 A
pgrid:           On-grid Export Power = 14 W
fgrid:           On-grid Frequency = 50.01 Hz
grid_mode:               Work Mode code = 1
grid_mode_label:                 Work Mode = Inverter On
vload:           Back-up Voltage = 0.0 V
iload:           Back-up Current = 2.3 A
pload:           On-grid Power = -254 W
fload:           Back-up Frequency = 50.01 Hz
load_mode:               Load Mode code = 0
load_mode_label:                 Load Mode = Inverter and the load is disconnected
work_mode:               Energy Mode code = 2
work_mode_label:                 Energy Mode = Normal (On-Grid)
temperature:             Inverter Temperature = 35.2 C
error_codes:             Error Codes = 0
e_total:                 Total PV Generation = 116.6 kWh
h_total:                 Hours Total = 365 h
e_day:           Today's PV Generation = 1.7 kWh
e_load_day:              Today's Load = 6.1 kWh
e_load_total:            Total Load = 395.7 kWh
total_power:             Total Power = -254 W
effective_work_mode:             Effective Work Mode code = 1
effective_relay_control:                 Effective Relay Control = 48
grid_in_out:             On-grid Mode code = 0
grid_in_out_label:               On-grid Mode = Idle
pback_up:                Back-up Power = 0 W
plant_power:             Plant Power = -254 W
meter_power_factor:              Meter Power Factor = 0.001
xx85:            Unknown sensor@85 = 0
xx87:            Unknown sensor@87 = -319
diagnose_result:                 Diag Status Code = 268437504
diagnose_result_label:           Diag Status = Self-use load light, SOC protect off
house_consumption:               House Consumption = 191 W

[lyricnz]

Copy/past from the HA issue:

Uksa007 commented 14 minutes ago •
@lyricnz Is there someway to just view the raw the values, I have a feeling that the current script is doing wrong maths and makes some of the values really hard to match to anything.

So far I have:

e_day: Today's PV Generation = 1.7 kWh should be e_day: Today's Battery output = 1.7 kWh
e_total: Total PV Generation = 116.6 kWh should be e_total: Total Battery output = 116.6 kWh
pgrid: On-grid Export Power = 14 W from meter (+export, -import seems backward)
plant_power: Plant Power = -254 W maybe AC ongrid power charge/discharge (+discharge -charging)

[lyricnz]

Hi @Uksa007

Most of the fields that you see in the sensors are just mapped directly from (runtime) bytes in the hex you saw above. There's some "sensor definition table" which is applied to the bytes - they start at "offset", have a size and unit etc.

Eg:

Here's the sensor table for the ES inverter (which seems to include BP)
https://github.com/marcelblijleven/goodwe/blob/master/goodwe/es.py

Actually, I've just noticed there is already a test for your inverter: https://github.com/marcelblijleven/goodwe/blob/master/tests/test_es.py#L300

[Uksa007]

Actually, I've just noticed there is already a test for your inverter:

Thats sounds good, how can I test it?
Seems like Mock data?

[craigcurtin-dev]

Hey guys, Just wanted to jump in here and mention that I was the one that originally got the ball rolling on the SBP integration stuff. At the time that it was all being put together (prior to it being an official integration) I had just received my 3 x SBP5000 units and was busy decoding them each evening using wireshark I went backwards and forwards with the developer sending him the outcome of throwing the various 241 and 245 codes at the inverters and I do not believe we ever got to the point of having a working fully decoded stream – so it was just shoe horned into the rest of it. As I was not a big HA user at the time (and still do not use the integration – as all my stuff is done in Node Red) then I did not worry too much Bottom line – I do not think this has ever been adequately decoded to the point that you can be comfortable that everything is going to line up. I am happy to provide more decode dumps etc if people want those. (although I have just changed out my Cisco switch so will have to do some work on how to do that in the Broacade environment with port mirroring etc) FWIW I send the 241 query code to my 3 inverters and get workable information about 90% of the time – I key off the value of the length of the return packet – if it is 149 bytes I use that and apply the offsets that interest me to decode. Also note that I do not use consumption monitoring feeding into my units so I can probably assist in what fields these populate as I have the ability to connect and disconnect the GoodWe GM1000D (single phase – dual CT clamps) Craig From: Simon Roberts ***@***.***> Sent: Sunday, October 23, 2022 11:19 AM To: marcelblijleven/goodwe ***@***.***> Cc: Craig Curtin ***@***.***>; Mention ***@***.***> Subject: Re: [marcelblijleven/goodwe] values for GW5000S-BP don't seem to match up (Issue #20) Hi @Uksa007<https://github.com/Uksa007> Most of the fields that you see in the sensors are just mapped directly from (runtime) bytes in the hex you saw above. There's some "sensor definition table" which is applied to the bytes - they start at "offset", have a size and unit etc. Eg: [image]<https://user-images.githubusercontent.com/122371/197366981-ec1c5902-6d8f-4046-ba74-6b87a8a4a9de.png> Actually, I've just noticed there is already a test for your inverter: https://github.com/marcelblijleven/goodwe/blob/master/tests/test_es.py#L300 — Reply to this email directly, view it on GitHub<#20 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6OST5D57KUCC3MVWW6FV3WER77BANCNFSM53R4O2VA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[Uksa007]

@lyricnz @craigcurtin-dev > Hey guys, Just wanted to jump in here and mention that I was the one that originally got the ball rolling on the SBP integration stuff. At the time that it was all being put together (prior to it being an official integration) I had just received my 3 x SBP5000 units and was busy decoding them each evening using wireshark I went backwards and forwards with the developer sending him the outcome of throwing the various 241 and 245 codes at the inverters and I do not believe we ever got to the point of having a working fully decoded stream – so it was just shoe horned into the rest of it. >>

Hi,
Yes I guess that what I'm seeing some things seems right(with wrong labels) some things just don't seem to match anything.
Would be really good to get fully decoded stream.
Developer seems to be AWAL, wondering how to progress, any idea?

[lyricnz]

Thanks for the tips @craigcurtin-dev. Is the SBP really too much different to the ES/EM/BP as implemented in es.py? (I saw the message about "Response has unexpected length: 149, expected 149" :/)

As far at this user is reporting, I haven't quite been able to get to the bottom of what they need. Clearly the labels say PV when it means battery (but so does semsportal - so who's to say when it should be different? may depend on runtime mode)

[lyricnz]

@Uksa007 if you don't like the labels in HA, you could just make a new sensor, with the labels you like, which gets its values from the "wrongly named" ones in the Goodwe integration.

[lyricnz]

I'll make a PR to make the 149 != 149 error message a bit more sane.

[Uksa007]

Way ahead of you there, I pretty much have managed to use the provided data, and calculate a few things, but would be good to fix it, so it's not so broken.

[lyricnz]

@Uksa007 I'm in HA discord if you want to chat in more realtime (but I'm not a maintainer of this module)

[Uksa007]

@craigcurtin-dev
So I take it that there is no documentation to decode the stream, it doesn't follow any of the modbus type data?

[craigcurtin-dev]

No when I was doing it – it did not appear to match up with the Modbus document that most people refer to for the GoodWe. What I did was basically step through changing individual things in the GoodWe phone app and then capturing what was being sent as output from the phone and the responses from the inverters. Once I had enough of these I was then able to put the ones I was interested into a spreadsheet and start comparing what was changing each time. I will try and setup my capture environment again this evening and report back when I can do some more captures. Do you have anything specific that you need to know or shall I just dump heaps of data at you ? Craig From: Uksa007 ***@***.***> Sent: Sunday, October 23, 2022 12:07 PM To: marcelblijleven/goodwe ***@***.***> Cc: Craig Curtin ***@***.***>; Mention ***@***.***> Subject: Re: [marcelblijleven/goodwe] values for GW5000S-BP don't seem to match up (Issue #20) @craigcurtin-dev<https://github.com/craigcurtin-dev> So I take it that there is no documentation to decode the stream, it doesn't follow any of the modbus type data? — Reply to this email directly, view it on GitHub<#20 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6OST55YEJXWYHLFOPFLZLWESFS3ANCNFSM53R4O2VA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[Uksa007]

@craigcurtin-dev > I will try and setup my capture environment again this evening and report back when I can do some more captures.
Thanks craig.

The following are a mystery to me:

vpv1: PV1 Voltage = 377.1 V                  Inverter Bus?
ipv1: PV1 Current = 1.3 A                    Inverter Bus?
ppv1: PV1 Power = 490 W                      Inverter Bus?
e_load_day: Today's Load = 6.1 kWh           Maybe Daily imported energy, but seems too high?
e_load_total: Total Load = 395.7 kWh         Maybe Total imported energy, but seems too high?
total_power: Total Power = -254 W            Same as plant_power?
plant_power: Plant Power = -254 W            AC power charged/discharged?
xx85: Unknown sensor@85 = 0
xx87: Unknown sensor@87 = -319
house_consumption: House Consumption = 191 W  Is not house consumption, not sure what it is?

Missing things may or maynot be available in the data stream:
Charging energy, eg how much energy you stored in the battery.

[craigcurtin-dev]

OK will get onto it and report back P.S. I am still waiting on getting day with 100% battery charge so I can send you over the dump from whirlpool also From: Uksa007 ***@***.***> Sent: Sunday, October 23, 2022 1:13 PM To: marcelblijleven/goodwe ***@***.***> Cc: Craig Curtin ***@***.***>; Mention ***@***.***> Subject: Re: [marcelblijleven/goodwe] values for GW5000S-BP don't seem to match up (Issue #20) @craigcurtin-dev<https://github.com/craigcurtin-dev> > I will try and setup my capture environment again this evening and report back when I can do some more captures. Thanks craig. The following are a mystery to me: vpv1: PV1 Voltage = 377.1 V Inverter Bus? ipv1: PV1 Current = 1.3 A Inverter Bus? ppv1: PV1 Power = 490 W Inverter Bus? e_load_day: Today's Load = 6.1 kWh Maybe Daily imported energy, but seems too high? e_load_total: Total Load = 395.7 kWh Maybe Total imported energy, but seems too high? total_power: Total Power = -254 W same as plant_power? plant_power: Plant Power = -254 W AC power charged/discharged? xx85: Unknown ***@***.*** = 0 xx87: Unknown ***@***.*** = -319 house_consumption: House Consumption = 191 W Is not house consumption, not sure what it is? Missing things may or maynot be available in the data stream: Charging energy, eg how much energy you stored in the battery. — Reply to this email directly, view it on GitHub<#20 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6OSTYYCJ24DB55QIFMTOLWESNMPANCNFSM53R4O2VA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[Uksa007]

So answering some of my own questions here, in es.py I found the below, it explains:

• Why house consumption is incorrect, it is using pv1 which seems like inverter power bus not solar, in fact it doesn't know solar power unless it pulls it from SEMS or maybe can calculate it somehow, still thinking on that.
• There looks to be a bunch of stuff commented out, missing sensors some of which i had to calculate manually, maybe it was a todo list that never got done?

        # Energy4("e_total_exp", 93, "Total Energy (export)", Kind.GRID),
        # Energy4("e_total_imp", 97, "Total Energy (import)", Kind.GRID),
        # Voltage("vpv3", 101, "PV3 Voltage", Kind.PV),  # modbus 0x500
        # Current("ipv3", 103, "PV3 Current", Kind.PV),
        # Byte("pv3_mode", 104, "PV1 Mode", "", Kind.PV),
        # Voltage("vgrid_uo", 105, "On-grid Uo Voltage", Kind.AC),
        # Current("igrid_uo", 107, "On-grid Uo Current", Kind.AC),
        # Voltage("vgrid_wo", 109, "On-grid Wo Voltage", Kind.AC),
        # Current("igrid_wo", 111, "On-grid Wo Current", Kind.AC),
        # Energy4("e_bat_charge_total", 113, "Total Battery Charge", Kind.BAT),
        # Energy4("e_bat_discharge_total", 117, "Total Battery Discharge", Kind.BAT),

        # ppv1 + ppv2 + pbattery - pgrid
        Calculated("house_consumption", 0,
                   lambda data, _:
                   round(read_voltage(data, 0) * read_current(data, 2)) +
                   round(read_voltage(data, 5) * read_current(data, 7)) +
                   (abs(round(read_voltage(data, 10) * read_current(data, 18))) *
                    (-1 if read_byte(data, 30) == 3 else 1)) -
                   (abs(read_power2(data, 38)) * (-1 if read_byte(data, 80) == 2 else 1)),
                   "House Consumption", "W", Kind.AC),
    )

[Uksa007]

@lyricnz
So what's the best plan of attack to start fixing this?
Should I fork it, make changes and hope @marcelblijleven accepts the pull request?

[lyricnz]

@Uksa007
I think that's the best approach. Even if they don't accept your PR, you can always install it into your local HA. You'd have to be super-careful not to break any of the other inverters supported by the same Inverter class. (I don't know if there's any model-specific kludgery). I have a fork with a couple of PRs I did while looking into your issue.

This module doesn't talk to semsportal, so the sensors can only reflect what the inverter itself knows. You might need to do any additional logic in the custom HA sensor.

Re: the commented out - it's more likely the list was cut and pasted from somewhere else, and those weren't applicable/correct for this inverter. You can look at the xx values to see if there's any useful-looking numbers in there.

[Uksa007]

@lyricnz > You'd have to be super-careful not to break any of the other inverters supported by the same Inverter class.

It looks like there was an old BP model which was a DC only, it sat between Solar panels and inverter with battery.
I was thinking of creating a new inverter class "S-BP", so it wouldn't interfere with the old BP inverter or any of the existing inverters.

Just trying to figure it out, python it not my native language :-p

[lyricnz]

I can see some device-specific kludges happen in DT read_device_info() - maybe it's okay to monkey around with self._sensors in some model-specific way. But the exact stuff you're expecting might also be mode-specific.

[Uksa007]

@lyricnz I want to change many things to be more model specific, so I think it might be safer to create new model class.
Have forked it, created new inverter class: SBP
https://github.com/Uksa007/goodwe/blob/master/goodwe/__init__.py

[Uksa007]

@lyricnz @craigcurtin-dev @marcelblijleven
Continue Discussion here
Uksa007#1

[mletenay]

As mentioned above, since the BP inverters seem to be that different from the (PV) inverters speaking the "ES" protocol, I suggest to go with dedicated class, so it does not break other families.
I'm happy to review and merge any changes, but you have to do the hard-work since I have no access to BP inverter to verify.

[lyricnz]

How are you going @Uksa007 ?

[Uksa007]

How are you going

@lyricnz Good, I have forked it and clean it up and it's looking good, just a couple of outstanding value I haven't been about to decode, @craigcurtin-dev was going to have a look but I think he has been busy.

Please see Uksa007#1