Testing on Anker SOLIX E1600

[smariacher]

I have bought some SOLIX E1600 which are ready to test. As of my understanding, solar power banks aren't really the main goal here, but as far as I can see the security protocol is exactly the same. I already tried out the test script using unknown which results in this output:

DEBUG:SolixBLE.device:Initializing Solix device 'Anker SOLIX E1600' withaddress 'E8:EE:CC:9D:C3:D0' and details 'RawAdvData(adv=<winrt._winrt_windows_devices_bluetooth_advertisement.BluetoothLEAdvertisementReceivedEventArgs object at 0x0000017F4D6ACBB0>, scan=None)'
DEBUG:bleak_retry_connector:E8:EE:CC:9D:C3:D0 - E8:EE:CC:9D:C3:D0: Connection attempt: 1
DEBUG:bleak.backends.winrt.client:Connecting to BLE device @ E8:EE:CC:9D:C3:D0
DEBUG:bleak.backends.winrt.client:getting services (service_cache_mode=None, cache_mode=None)...
DEBUG:bleak.backends.winrt.client:session_status_changed_event_handler: id: BluetoothLE#BluetoothLE50:bb:b5:85:c6:91-e8:ee:cc:9d:c3:d0, error: <BluetoothError.SUCCESS: 0>, status: <GattSessionStatus.ACTIVE: 1>
DEBUG:bleak.backends.winrt.client:max_pdu_size_changed_handler: 256
DEBUG:bleak.backends.winrt.client:E8:EE:CC:9D:C3:D0: services changed
DEBUG:bleak.backends.winrt.client:E8:EE:CC:9D:C3:D0: services changed
DEBUG:bleak_retry_connector:E8:EE:CC:9D:C3:D0 - E8:EE:CC:9D:C3:D0: Connected after 1 attempts
DEBUG:SolixBLE.device:Established initial connection to 'Anker SOLIX E1600' on attempt 1!
DEBUG:SolixBLE.device:Subscribing to notifications from device 'Anker SOLIX E1600'!
DEBUG:SolixBLE.device:Sending negotiation initiation request to 'Anker SOLIX E1600'...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, E8:EE:CC:9D:C3:D0
DEBUG:SolixBLE.device:Received notification from 'Anker SOLIX E1600'. length: 14, packet: 'ff090e00030001080100a1010152'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0801
DEBUG:SolixBLE.device:Payload: 00a10101
DEBUG:SolixBLE.device:Payload length: 4
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 1 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '01'}
DEBUG:SolixBLE.device:Sending stage 1 response message...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, E8:EE:CC:9D:C3:D0
DEBUG:SolixBLE.device:Received notification from 'Anker SOLIX E1600'. length: 27, packet: 'ff091b00030001080300a10102a202fd00a30144a40101a50102ff'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0803
DEBUG:SolixBLE.device:Payload: 00a10102a202fd00a30144a40101a50102
DEBUG:SolixBLE.device:Payload length: 17
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 2 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '02', 'a2': 'fd00', 'a3': '44', 'a4': '01', 'a5': '02'}
DEBUG:SolixBLE.device:Sending stage 2 response message...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, E8:EE:CC:9D:C3:D0
DEBUG:SolixBLE.device:Received notification from 'Anker SOLIX E1600'. length: 56, packet: 'ff093800030001082900a10103a2054553503332a307302e302e302e33a410415a5636593630443332323030353834a506e8eecc9dc3d01e'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0829
DEBUG:SolixBLE.device:Payload: 00a10103a2054553503332a307302e302e302e33a410415a5636593630443332323030353834a506e8eecc9dc3d0
DEBUG:SolixBLE.device:Payload length: 46
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 3 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '03', 'a2': '4553503332', 'a3': '302e302e302e33', 'a4': '415a5636593630443332323030353834', 'a5': 'e8eecc9dc3d0'}
DEBUG:SolixBLE.device:Sending stage 3 response message...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, E8:EE:CC:9D:C3:D0
DEBUG:SolixBLE.device:Received notification from 'Anker SOLIX E1600'. length: 11, packet: 'ff090b00030001080500f2'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0805
DEBUG:SolixBLE.device:Payload: 00
DEBUG:SolixBLE.device:Payload length: 1
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 4 due to response from device!
DEBUG:SolixBLE.device:Parameters: {}
DEBUG:SolixBLE.device:Sending stage 4 response message...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, E8:EE:CC:9D:C3:D0
DEBUG:SolixBLE.device:Received notification from 'Anker SOLIX E1600'. length: 77, packet: 'ff094d00030001082100a1404c8cd214e1886dfa9aa22da85579166a8b8eb57a4e238dea6025ff19c236bf039cd8bef8067371bd3e0e88b4ea90e58a573326aca556d2a9953c89068e490c85e3'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0821
DEBUG:SolixBLE.device:Payload: 00a1404c8cd214e1886dfa9aa22da85579166a8b8eb57a4e238dea6025ff19c236bf039cd8bef8067371bd3e0e88b4ea90e58a573326aca556d2a9953c89068e490c85
DEBUG:SolixBLE.device:Payload length: 67
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 5 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '4c8cd214e1886dfa9aa22da85579166a8b8eb57a4e238dea6025ff19c236bf039cd8bef8067371bd3e0e88b4ea90e58a573326aca556d2a9953c89068e490c85'}
DEBUG:SolixBLE.device:Public key of device: 044c8cd214e1886dfa9aa22da85579166a8b8eb57a4e238dea6025ff19c236bf039cd8bef8067371bd3e0e88b4ea90e58a573326aca556d2a9953c89068e490c85
DEBUG:SolixBLE.device:Shared secret: a985ca66e79304923f717fcfd95b084a62cf7e0c3bb1f243ef520e339fc0e10f
DEBUG:SolixBLE.device:AES key: a985ca66e79304923f717fcfd95b084a
DEBUG:SolixBLE.device:AES IV: 62cf7e0c3bb1f243ef520e339fc0e10f
DEBUG:SolixBLE.device:Sending stage 5 response message...
DEBUG:SolixBLE.device:Negotiations with 'Anker SOLIX E1600' succeeded!
==== REMOTE STATE CHANGE DETECTED ====
Generic(
    ADDRESS: E8:EE:CC:9D:C3:D0,
    AVAILABLE: False,
    CONNECTED: True,
    LAST_UPDATE: None,
    NAME: Anker SOLIX E1600,
    NEGOTIATED: True,
)
==== END OF STATE CHANGE REPORT ====

State changes aren't displayed in the debug info, at least the output power changing isn't displayed. Maybe someone else with a better understanding of what they are doing has an idea how to continue.

[smariacher]

I have tried out Solarbank 2, the second state report came out like this:
The first state report's values were all -1, if that is of any interest

Solarbank2(
    AC_POWER_OUT: 19.1,
    AC_POWER_OUT_SOCKETS: KeyError: 'c8',
    ADDRESS: E8:EE:CC:9D:C3:D0,
    AVAILABLE: True,
    BATTERY_CHARGE_POWER: 0.0,
    BATTERY_DISCHARGE_POWER: 3533498814.09,
    BATTERY_PERCENTAGE: 93,
    BATTERY_PERCENTAGE_AGGREGATE: 1,
    CHARGED_ENERGY: 0.0,
    CONNECTED: True,
    CONSUMED_ENERGY: KeyError: 'c9',
    GRID_EXPORT_ENERGY: 0.0,
    GRID_IMPORT_ENERGY: 0.0,
    GRID_TO_HOME_POWER: 0.0,
    HOUSE_DEMAND: KeyError: 'c4',
    LAST_UPDATE: 2026-03-20 16:56:41.292263,
    NAME: Anker SOLIX E1600,
    NEGOTIATED: True,
    OUTPUT_ENERGY: 0.033,
    POWER_OUT: KeyError: 'd3',
    PV_TO_GRID_POWER: 0.0,
    PV_YIELD: 0.0,
    SERIAL_NUMBER: AZV6Y60D32200584,
    SOFTWARE_VERSION: 2.1.5,
    SOFTWARE_VERSION_CONTROLLER: 2.1.5,
    SOFTWARE_VERSION_EXPANSION: 1.2.2,
    SOLAR_POWER_IN: 0.0,
    SOLAR_PV_1_POWER_IN: KeyError: 'ca',
    SOLAR_PV_2_POWER_IN: KeyError: 'cb',
    SOLAR_PV_3_POWER_IN: KeyError: 'cc',
    SOLAR_PV_4_POWER_IN: KeyError: 'cd',
    TEMPERATURE: 11,
)
==== END OF STATE CHANGE REPORT ====

[thomluther]

That looks to me as wrong message format from SB2 is used for SB1 models.
The 3 SB generations have different telemetry formats as you can see in the api-library:

• SB1 0405
• SB2 0405
• SB3 0405

@smariacher
How did you get the SB1 BT connection? Does BT work at all after you created the system and the SB is Wifi connected? Is there something you have to do to start the BT communication of the device?

[smariacher]

Oh sorry my previous messages were explaining what I am doing poorly. I have used the Solarbank2 class with my (physical) Solarbank (1) E1600. This is how I got the Solarbank2 output.
So to answer your question, BT connection works out of the box, using the "Complex Example" from the documentation, and selecting Solarbank2.

From that I have copied over all the properties from the Solarbank2 class into a new Solarbank1 class, and already changed the ac_power_out to not divide by 10. This results in the correct value. All the values you can see above in my previous reply are already coming from the SB1 and seem to be mostly correct.

I will have a look at the API library you shared and see if those commands get me any further. Other than that, I am willing to try out anything you guys can suggest.

[thomluther]

So to answer your question, BT connection works out of the box, using the "Complex Example" from the documentation, and selecting Solarbank2.

I have a SB1 as well and when I try to discover BT devices, nothing is found...My Laptop is only 3-4 m away from the device, so it should be discovered. But there is nothing and I assume BT is disabled by the Solarbank.

[thomluther]

I will have a look at the API library you shared and see if those commands get me any further. Other than that, I am willing to try out anything you guys can suggest.

You will have to create a new device class since you cannot reuse Solarbank2 class as is. It has other telemetry data.

[smariacher]

You will have to create a new device class since you cannot reuse Solarbank2 class as is. It has other telemetry data.

Yeah already did that, I am currently implementing all the things from anker-solix-api gh. I will keep you posted on that.

I have a SB1 as well and when I try to discover BT devices, nothing is found...My Laptop is only 3-4 m away from the device, so it should be discovered. But there is nothing and I assume BT is disabled by the Solarbank.

That could be the reason. I was able to change that inside the app. Also they seem to report not as often when scanning, sometimes I have to let the complex example run pretty long until it finds the SB1. Then it first spits out no values, so only prints default values. After a while tough it changes to actually reporting values.

[smariacher]

This is the new output after implementing everything I understood from the anker-solix-api gh.

Solarbank1(
    ADDRESS: E8:EE:CC:9D:C3:D0,
    AVAILABLE: True,
    BATTERY_CHARGE_POWER: 0.0,
    BATTERY_PERCENTAGE: 78,
    CHARGED_ENERGY: 0.0,
    CHARGING_STATUS: 1,
    CONNECTED: True,
    HARDWARE_VERSION: 1.2.2,
    INVERTER_BRAND: ANKER,
    INVERTER_MODEL: A5143,
    LAST_UPDATE: 2026-03-20 18:34:43.141051,
    MIN_LOAD: 100,
    NAME: Anker SOLIX E1600,
    NEGOTIATED: True,
    OUTPUT_ENERGY: 0.2593,
    OUTPUT_POWER: 95,
    PV_YIELD: 0.0,
    SERIAL_NUMBER: AZV6Y60D32200584,
    SOFTWARE_VERSION: 2.1.5,
    SOFTWARE_VERSION_CONTROLLER: 2.1.5,
    SOLAR_POWER_IN: 0.0,
    TEMPERATURE: 21,
)

Here are all the properties so far:

@property
    def serial_number(self) -> str:
        """Device serial number.

        :returns: Device serial number or default str value.
        """
        return self._parse_string("a2", begin=1)

    @property
    def battery_percentage(self) -> int:
        """Battery Percentage.

        :returns: Percentage charge of battery or default int value.
        """
        return self._parse_int("a3", begin=1)

    @property
    def software_version(self) -> str:
        """Main software version.

        :returns: Firmware version or default str value.
        """
        if self._data is None:
            return DEFAULT_METADATA_STRING

        return ".".join([digit for digit in str(self._parse_int("a6", begin=1))])

    @property
    def software_version_controller(self) -> str:
        """Software version of the controller.

        :returns: Firmware version or default str value.
        """
        if self._data is None:
            return DEFAULT_METADATA_STRING

        return ".".join([digit for digit in str(self._parse_int("a7", begin=1))])

    @property
    def hardware_version(self) -> str:
        """Hardware version.

        :returns: Hardware version or default str value.
        """
        if self._data is None:
            return DEFAULT_METADATA_STRING

        return ".".join([digit for digit in str(self._parse_int("a8", begin=1))])

    @property
    def temperature(self) -> int:
        """Temperature of the unit (C).

        :returns: Temperature of the unit in degrees C.
        """
        return self._parse_int("aa", begin=1, signed=True)

    @property
    def solar_power_in(self) -> int:
        """Total Solar Power In.

        :returns: Total solar power in or default float value.
        """
        if self._data is None:
            return DEFAULT_METADATA_FLOAT

        return self._parse_int("ab", begin=1) / 10.0

    @property
    def output_power(self) -> int:
        """Output power.

        :returns: Total power out in watts or default float value.
        """
        if self._data is None:
            return DEFAULT_METADATA_FLOAT

        return self._parse_int("ac", begin=1)

    @property
    def charging_status(self) -> int:
        """Charging status.

        :returns: Charging status or default int value.
        """
        return self._parse_int("ad", begin=1)

    @property
    def battery_charge_power(self) -> int:
        """Battery charging power.

        :returns: Total battery power in or default float value.
        """
        if self._data is None:
            return DEFAULT_METADATA_FLOAT

        return self._parse_int("b0", begin=1) / 100.0

    @property
    def pv_yield(self) -> int:
        """Solar power generated.

        :returns: Total solar power generated or default float value.
        """
        if self._data is None:
            return DEFAULT_METADATA_FLOAT

        return self._parse_int("b1", begin=1) / 10000.0

    @property
    def charged_energy(self) -> int:
        """Probably aggregated energy charged in Wh?

        :returns: Charged energy or default float value.
        """
        if self._data is None:
            return DEFAULT_METADATA_FLOAT

        return self._parse_int("b2", begin=1) / 10000.0

    @property
    def output_energy(self) -> int:
        """Output energy.

        :returns: Total energy output or default float value.
        """
        if self._data is None:
            return DEFAULT_METADATA_FLOAT

        return self._parse_int("b3", begin=1) / 10000.0

    @property
    def inverter_brand(self) -> str:
        """Brand of the connected inverter.

        :returns: Inverter brand or default str value.
        """
        if self._data is None:
            return DEFAULT_METADATA_STRING

        return self._parse_string("b7", begin=1) # TODO: Check this later

    @property
    def inverter_model(self) -> str:
        """Model of the connected inverter.

        :returns: Inverter model or default str value.
        """
        if self._data is None:
            return DEFAULT_METADATA_STRING

        return self._parse_string("b8", begin=1) # TODO: Check this later

    @property
    def min_load(self) -> int:
        """Maybe minimum wattage the battery will output?

        :returns: Don't know yet or default str value.
        """
        if self._data is None:
            return DEFAULT_METADATA_STRING

        return self._parse_int("b9", begin=1) # TODO: Check this later

So it seems that all of these work so far. Controlling the SB1 would be the next big step.

[smariacher]

Small update
I was able to add another readout I couldn't find in the anker-solix-api gh, which is the readout for when how much power can be drawn by the connected inverter. For context, this can be set inside the Anker app schedule wise, so e.g. from 00:00 to 12:00 draw a maximum of 150W and from 12:30 to 24:00 draw 100W. Between, so from 12:00 to 12:30 it will automatically draw 200W, which is the default. This is not communicated and seems to be the default on both ends, solarbank and app that is.

Additionally the message from the solarbank has info about the discharge limits, which I don't quite understand yet. What I think it controls is the SOC at which the solarbank either stops or starts discharging to the grid (via the inverter of course).
Here is the function:

@property
    def current_schedule(self) -> str:
        """Parse the active daily schedule block(s).
        
        :returns: A human-readable string describing the current schedule or a message if no schedule is set.
        """
        if self._data is None or "ae" not in self._data:
            return "No Schedule Set"

        data = self._data["ae"]
        
        # Safely extract the raw bytes
        if isinstance(data, bytes):
            raw_bytes = data
        elif isinstance(data, dict):
            hex_str = data.get('hex', '')
            raw_bytes = bytes.fromhex(hex_str)
        else:
            return "Invalid data format"

        # A valid payload has a 1-byte header, plus N * 8-byte blocks
        if len(raw_bytes) < 9 or (len(raw_bytes) - 1) % 8 != 0:
            return f"Unknown structure: {raw_bytes.hex()}"

        # We can ignore the first byte (04 header) and loop through the rest
        periods = []
        for i in range(1, len(raw_bytes), 8):
            chunk = raw_bytes[i:i+8]
            
            start_min = int.from_bytes(chunk[0:2], byteorder='little')
            end_min = int.from_bytes(chunk[2:4], byteorder='little')
            watts = int.from_bytes(chunk[4:6], byteorder='little')
            limit = int.from_bytes(chunk[6:8], byteorder='little')

            start_time = f"{start_min // 60:02d}:{start_min % 60:02d}"
            end_time = f"{end_min // 60:02d}:{end_min % 60:02d}"
            
            periods.append(f"[{start_time}-{end_time} @ {watts}W, Limit: {limit}%]")

        return " | ".join(periods)

The corresponding output looks like this:
CURRENT_SCHEDULE: [00:00-12:00 @ 150W, Limit: 80%] | [12:30-24:00 @ 100W, Limit: 80%]

Maybe this helps someone to find out what the command structure and hex to change this could be. I will be working on that as well.

[thomluther]

From what I have seen in MQTT messages from SB1 E1600, this seems to be managed quite differently than later generations.
Later generations have the schedule information in the device (controlled by Api controls, which trigger the Cloud to send complex MQTT commands with the schedule settings, usage mode etc). This will become difficult to control only via BT/MQTT, since the custom output power can only be modified within the whole custom schedule change.

Now, the SB1 seems to behave differently, there is no message that I have seen containing the whole schedule, instead the cloud sends regular command every 55 seconds containing the actual output preset (based on cloud scheduling I guess), the SOC limits, and timeout and a few other settings.

So I don't know, whether you can easily control the output of a solarbank 1 locally, since this may be overwritten by cloud controls that act upon the schedule provided via Api...

[thomluther]

Another update on BT connection of SB1.
I had to press the right button (IOT Button/Wifi Button) shortly to re-enable BT. Afterwards the scanner found it and I could also connect.
Not sure however, how long the BT capability will be maintained if interrupted. You may always have to press the IOT button shortly before a reconnection is possible after a 'longer' outage.

[smariacher]

Another update on BT connection of SB1. I had to press the right button (IOT Button/Wifi Button) shortly to re-enable BT. Afterwards the scanner found it and I could also connect. Not sure however, how long the BT capability will be maintained if interrupted. You may always have to press the IOT button shortly before a reconnection is possible after a 'longer' outage.

That's interesting. To get on the same page here is what I did to setup my SB1.
Connect to it via the Anker app, do the initial setup and then after being prompted how I want to manage my SB1 I chose BLE. After this I can connect to it just fine via BLE using the app or with the script. It doesn't really matter how long I am not connected or if the SB1 is at 10% SOC (it doesn't blink anymore so I initially thought that it goes into a deep standby, only listening to button inputs).

I have currently two SB1's set up near my PC, one at 10% as mentioned and one at around 20%. Both can be connected to and give readouts just fine (although the first readout always seem to contain no information, meaning all values default to -1 etc.)

So I don't know, whether you can easily control the output of a solarbank 1 locally, since this may be overwritten by cloud controls that act upon the schedule provided via Api...

I don't have the SB1's connected to cloud, as mentioned, and don't plan on doing that. I want to control them completely locally, probably using an ESP32 per SB1 to connect via BLE, save the information and switch to Wifi to relay everything to my local HA.

Also since you are having problems, just FYI, I don't think the SB1 can connect to Wifi and BLE at the same time, because they probably have something similar to an esp32 inside them handling wireless connections and chips like the esp32 can only do one at a time, Wifi or bluetooth but not both.

[thomluther]

Also since you are having problems, just FYI, I don't think the SB1 can connect to Wifi and BLE at the same time, because they probably have something similar to an esp32 inside them handling wireless connections and chips like the esp32 can only do one at a time, Wifi or bluetooth but not both.

That might be true.
Just a few hours later after I made the connection test I checked that I could reconnect BT.
When I later checked my HA integration from the cloud, it showed unavailable entities. So I had to press the IOT button again to make it re-connect to Wifi.

Since my automation is running through the Api, that is a big limitation not being able to use in parallel...

[flip-dots]

@smariacher This is some great work, do you plan on submitting a PR or would you rather I add it (I am fine with either).

I sort of just added the Solarbank classes on a whim because the format was already decoded from anker-solix-api, its great that it actually works (even if its just the negotiation that works).

The telemetry values not updating for a while is usually because Anker devices only send updates when things change, so if nothing is plugged in you get no updates because there are no changes, but it might be different for these devices. There is also a command that can be sent to request a telemetry update and I implemented that for the C300(X), C800(X), and C1000(X) power stations, the same command might work for yours.

In terms of adding controls for other functionality, what I did was capture the packets the app sent and dumped its shared preferences so I could decrypt the packets and that helped me figure out what command bytes did what and how to replicate it.

[smariacher]

@flip-dots Thanks a lot! I plan on submitting a PR once I have another look at the class structure and hopefully after being able to control the output power via BLE.

In terms of adding controls for other functionality, what I did was capture the packets the app sent and dumped its shared preferences so I could decrypt the packets and that helped me figure out what command bytes did what and how to replicate it.

Logging the bluetooth packets is also something I tried, although I couldn't figure out what exact message format the app uses for controlling the output wattage. By dumping its shared preferences, do you mean you dumped your phones memory while running the app? I tried running it inside an emulator, but it seems that Anker has some measures that leads to crashing the app if it detects an emulator environment. I can share the specific BLE package here, I just have to figure out what I can and can't share online.

[thomluther]

I tried running it inside an emulator, but it seems that Anker has some measures that leads to crashing the app if it detects an emulator environment.

I tried that too some while ago, but I had only emulators without BT emulation. I assume the App needs a BT adapter (emulation) mandatory, otherwise it will not work.

I couldn't figure out what exact message format the app uses for controlling the output wattage.

My test with MQTT messages showed that the App is not sending something to the device directly when modifying the custom schedule or output preset within it.

Rather there is an Api request with the schedule object to be applied in the cloud, and the cloud is then driving regular MQTT messages with certain states for the device as documented here. I called the command status check, although meanwhile I think it could be a kind of scheduled device control driven by the cloud. But I never saw this message type coming directly from the App client.

So the question is, can you apply a schedule to the device at all via BT only? Then the schedule must somehow being contained in the messages.