Feedback #2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Firstly thank you for doing this work - lucky that i found it at right time. I have several AI pumps etc none of which appear. However since today's release I can now see my MXM (which i don't use anymore but is still plugged in). I have 1 Axis 20, 2 Orbit 20, and 1 Blade Freshwater. I have 1 "Failed Setup" - no idea which of above that might be - and why the others aren't being seen - I can see several in the Bluetooth part of HA. Is there anything I can give you that might help?
thanks for the feedback!
Can you also check the BT signal level (RSSI) on the Bluetooth page? Example:
Pic 1 shows current screen. Previous version I had 2 failed setup. Now i see the MXM.
Pic 2 shows the log - I had debug turned on already
Pic 3 is my Blutooth screen
Outside of the Fresh water blade - all other devices are in my marine Cabinet. (including the MXM)
and deleted the two items found (MXM and failed). Redownloaded software. Rebooted.
I can now see Discovered the MXM as expected, and the BladeFreshwater.Clicked on Add for them both.
Blade connects this time, MXM is less happy, and doesn't seem to want to work (failed setup).
I wonder if this is a poor blutooth connection
when you have debug logging on the integration enabled you should see something like this:
When you press "Disable", it will download the log file.
Have you deleted the devices there?
@deutscs wrote in #2 (comment):
signal is good enough but it might be (the debug logs will tell)
MXM is something i really haven't tested (i only have tested this on ecotech HW). there were some codepaths that i haven't implemented that can be related to it, get me those debug logs and the diagnostic info from any device on the integration and i'll try to make it work...
ok - doing the debug bit now (deleted devices again as instructed) and rebooted. PS I don't care about MXM. Will disappear when I disconnect my Neptune. Blade connected fine as before. MXM failed.
Added the debug file.
MXM is now working!!! weird :)
But still missing all the other devices....
sure you added the correct file? that one is mostly empty 😅
I am not at home - so added complication. New file is right I hope
good, now i'm only missing the Diagnostics. with that I should be able to understand what's happening...
Here you go
well... yea, it might actually be that BT connection isn't stable enough:
You have some BT adapters that can see the devices, but aren't able to connect to it. you might just be luckier if you add one close to the tank or move one to be closer...
From the logs, you have the BladeFreshwater in one tank and the others probably on another tank (Mobius app speaking). It did actually connect to the BladeFreshwater, but the others it couldn't connect to, that's why they don't show up.
They might actually work from time to time, but right now, the signal is way too weak.
ok - when i get home I have a USB Bluetooth adapter. Will try to plug that in close to tank - and see what happens. I will keep you posted.
Hello - just to keep you in the picture. While I plugged in a Shelley Bluetooth USB it made no difference. Claude (AI) thinks it is only my HA Server that has the ability to connect and that is in a different room - hence issues. It suggested I ordered a M5Stack Official ATOMS3 Lite ESP32S3 Dev Kit so I can have a "proper" active bluetooth proxy. This should sort the connection problem - for MXM anyway. Whether it identifies the 3 missing AI pumps remains to be seen. Arrives tomorrow - will keep you informed.
Yeah. I got some cheap ESP32 and installed ESPHome with bluetooth_proxy on one of them to get good connection near the tank.
I'll keep this one open until you sort that out so that we can debug further if/when you get a new BT device near the tank. Meanwhile, I'll check if I'm missing something for the AI pumps. Can you show me your tank setup on the mobius app (devices per tank)?
here you go. I can see the Vectra S2. I dusted it off to see if I could see it. Not installed in tank - in same room as server.
ok so 1 tank with:
another tank just with the MXM.
Is that correct?
(the integration should see the vectra as part of the tank, even if it doesn't get any information from it)
MXM is also on that tank but only shows on devices rather than dashboard. (I dont really care about MXM - it isnt used anymore - I just hadnt turned it off and to be honest if it was I would be managing the pumps via the Neptune Apex App). The other tank is a Tropical Tank and has the Blade.
ok - good afternoon. So new BluTooth Proxy is up and running. The MXM is now picked up and (as much as it only operates as a Gateway into Neptunes Apex system) appears functional. Nothing else is picked though. So it cant seem to see / identify AI Orbit 20s or Axis 20s. Let me know if you would like any more information from me.
if you had anything setup before, delete every device leaving the integration empty and then reboot homeassistant. it should pick up 2 tanks automatically after that.
BT has some quircks that I tried to mitigate but sometimes it still missbehave 🤷♂️
Right - things are looking more positive. Will report back shortly
ok - so after a few reboots, I think things are ok. It was losing the connection after 30 seconds or so - but thats seems to have stopped now - attributes were just coming up as unknown. So on basis that this carries on working - it looks good. 1 Question - how is estimated flow being done - are you calculating it or is it part of data from pump. Axis 20 is almost certainly wrong.
If it keeps going to unknown, just enable debug log for 10/15 minutes and attach it again. The values are fetched from the devices every 30s.
Flow is from the pump. I verified the values again mine (ecotech), but AI might use another value. A screenshot of both the value on Hass and the value mobius shows would be helpful there...
You can clearly see why it has to be wrong!!!
Out of interest is the 30sec hard coded? or is there potential to change it? The flow pumps (Orbits) are changing all the time
PS Mobius App doesn't show flow rate - just %. (As far as I can see)
Yeah... Definitely looks wrong 😅
Right now it's hard coded. I plan to make it configurable per-tank later.
Hummmm that might be a clue that we can't trust those values. I'll dig into it.
Do the values change every 30s ? (motor speed and estimated flow) if they do, they actually report something, just need to understand what
Yes - it does appear to as the graph is showing min of 1% and max of 60% - which is what it should be. However you can see it has gone "Unavailable". Other pumps are ok though
Yeah, the graphs are the important thing IMO. Instant values aren't always reliable. For example, I sometimes get 11k L/h as flow with a motor speed of 0% on my vortechs. 🤷♂️
To see the why that unavailable happens just with the debug log.
This error originated from a custom integration.
Logger: custom_components.mobius.gateway_registry
Source: custom_components/mobius/gateway_registry.py:392
Integration: Mobius (documentation, issues)
First occurred: 17:20:47 (7 occurrences)
Last logged: 17:33:54
This error originated from a custom integration.
Logger: custom_components.mobius.coordinator
Source: helpers/update_coordinator.py:506
Integration: Mobius (documentation, issues)
First occurred: 17:19:34 (5 occurrences)
Last logged: 17:28:53
Still too far? 🤔 Can't you place the proxy right near the tank?
mine only work decently with at least -65 RSSI.
Might add a file to detail what's needed and what I have working. Or just add the info to the README...
Good Morning. The proxy is super close to tank - it really cant be that. I have worked with Claude to try and bug fix last night. We are trying one more thing then I will ask him to write a condensed note of everything we did and what he thinks.... give me an hour or so - I have to do real world work as well,,,,
It is up and running at moment - Claude is checking every 5 minutes for 2 hours, then will report back
here is report -----
Mobius Marine Aquarium — Summary Report
Monitoring Result (08:22–11:44 today)
Zero drops. 3h 22m continuous stable operation. All 4 devices polling normally, VectraS2 holding as gateway throughout.
Device Inventory
What We Diagnosed & Fixed
Problem 1: Neptune MXM BLE conflict (root cause of all recurring failures)
The Neptune Apex MXM module was maintaining a persistent BLE connection to the VectraS2 pump at all times in order to relay pump data to the Apex controller. This left no BLE connection slot free for the Mobius HA integration. Every time HA tried to connect to VectraS2, it was silently refused.
This explained:
Fix: MXM removed from Apex Fusion config and physically unplugged. VectraS2 power-cycled to reset its BLE stack. Integration reloaded — stable ever since.
Problem 2: SCAN_RSP / active scanning (historical — resolved by ATOM Lite)
The Realtek BT adapter on the HA server was too far from the marine tank to reliably catch SCAN_RSP packets, which contain the device serial number. Without the serial, the Möbius integration cannot identify VectraS2 in the BLE cache.
Fix: M5Stack ATOM Lite C124 flashed with ESPHome bluetooth_proxy: active: true and placed near the tank. Active scanning sends SCAN_REQ and receives SCAN_RSP, providing serials to HA's BLE cache.
Current Device Status
Recommended Code Changes for the Möbius Integration
Bug 1 — Critical: Aqua Illumination devices use BLE company ID 1, not 514
The python-mobius library and the HA integration hardcode MOBIUS_COMPANY_ID = 514 (EcoTech/Neptune format). All three Aqua Illumination devices (Orbit 2 ×2, Axis 20) advertise under company ID 1 with an identical payload structure:
Affected code in coordinator.py:
python
Copy
payload = info.manufacturer_data.get(MOBIUS_COMPANY_ID) # misses AI devices
And in init.py _current_rssi():
python
Copy
payload = info.manufacturer_data.get(MOBIUS_COMPANY_ID) # AI pumps get None → sorted last
Fix: Search both company IDs when scanning:
python
Copy
KNOWN_COMPANY_IDS = {514, 1}
for cid in KNOWN_COMPANY_IDS:
payload = info.manufacturer_data.get(cid)
if payload:
break
Bug 2 — Moderate: Orbit 2 Back (A0770012F5RBB1) relay path goes through an AI pump
A0770012F5RBB1 is a Thread end device whose parent in the mesh is the Axis 20 (8W7900069BRBD4). When the integration needs to relay to A0770012F5RBB1, it tries to BLE-connect to 8W7900069BRBD4 as a secondary gateway — but cannot find it because of Bug 1 (company ID 1). Currently working only because VectraS2's initial mesh discovery cached A0770012F5RBB1's Thread address directly at setup. If that cache expires, the relay will fail again.
Fix: Same as Bug 1 — fixing the company ID lookup allows 8W7900069BRBD4 to be found as a BLE relay gateway when needed.
Bug 3 — Minor: No warning about competing BLE clients
There is no warning in the config flow or documentation that third-party BLE clients (Neptune MXM, Möbius iOS/Android app) holding an active connection to the gateway device will silently block HA from connecting. Users can spend hours debugging what presents as an intermittent availability issue with no obvious cause.
Worth adding a note in the config flow UI and/or README: "Ensure no other devices (Apex MXM module, Möbius mobile app) are actively BLE-connected to your gateway device during setup and normal operation."
Nothing Else Needs Changing in Your HA Setup
The ATOM Lite proxy, Marine Aquarium config entry, and BLE scanner configuration are all correct. The only systemic risk remaining is if something else takes the VectraS2's BLE slot again — with MXM permanently removed, there is no known device that would do this.
Hello - just had to do a reboot, and it stopped working again. Here is Claudes summary :
Title: Axis20 pump (AI Axis 20, company ID 1) loses support after HA restart — mesh address cached but device marked "unsupported"
Environment:
Summary:
Before a routine Home Assistant restart, this device was fully functional — firmware_version: 2.3.15, error_state: NoError, schedule_points: 1. After the restart:
support_tier flipped from pump → unsupported
error_state, schedule_points, firmware_version, hardware_revision all went to unknown
mesh_address is the only attribute still populated — it's a cached/static value, not live-polled
Timeline:
Suspected root cause:
This looks like the same issue as a previously-reported bug in this setup: AI (Aqua Illumination) devices — this Axis 20, and separately an Orbit 2 Flow Pump (A0770012F5RBB1) that relays through this same Axis 20 — advertise via BLE company ID 1, but python-mobius's device discovery (_find_in_bluetooth_cache / _current_rssi) only searches company ID 514. Before the restart, a cached Thread mesh address let the integration skip fresh discovery and it worked fine. The restart cleared that cache, forcing a fresh discovery pass, which hit the company-ID mismatch and marked the device unsupported — even though the raw BLE advertisement was received (per the last_seen timestamp).
Suggested fix: search both company ID 1 and 514 in _find_in_bluetooth_cache and _current_rssi, rather than only 514.
Workaround: power-cycling the affected device forces re-advertisement and has previously restored function, but the underlying discovery bug means any future cache-clearing event (HA restart, BLE proxy reconnect, etc.) will likely reproduce this.
I need you to verify something. The company ID is actually 2 bytes and the 01 is just the low byte. I need you to confirm what is the hight byte. You can see it on Home Assistant Bluetooth Advertisements. Try to find one of your AI pumps/gyros with the full info. Something like what's attached
{"name":"MOBIUS","address":"D5:FA:10:E4:63:AA","rssi":-74,"manufacturer_data":{"1":"0501010100000026f43857373930303036394252424434"},"service_data":{},"service_uuids":["01ff0100-ba5e-f4ee-5ca1-eb1e5e4b1ce0"],"source":"54:F2:9F:AB:60:D7","connectable":true,"time":1787380178.5822055,"tx_power":null,"raw":"0201041106e01c4b5e1eeba15ceef45eba0001ff0107084d4f42495553"}
Sorry to bother you with this, but since you have an MXM, can you check it's value too?
ok, everything should work with version 0.4.0. if for some reason it doesn't, feel free to open the bug again. and thx for all the help 😉