jmoor3 / homeassistant-components

3 stars 19 forks source link

3rd pump? #5

Closed plmilord closed 4 years ago

plmilord commented 5 years ago

Everything's work great for me with that script from jmoor 3... Excellent work!

I own a Coast Spa with 3 pumps. The script only take care of 2 pumps. Any ideas on what should be the hexadecimal mask for that 3rd pump?

Ideas...? let me know!

Regards,

jmoor3 commented 5 years ago

Are you asking about the status or the toggle?

For status, my guess is that it uses two bits for each pump from smallest to largest. So pump one is 0x3 for the last two bits (0000011), pump two is 0x12 for the next two bits after that (0001100) and by deduction you want to mask 0x48 (0110000) for pump 3.

For toggle I’d gues 0x6 or 0x7 because pump 1 and 2 are 0x4 and 0x5.

I don’t have a third pump so let me know if this works and submit a pull :)

plmilord commented 5 years ago

Thank you very much for your advice! I'm improving gradually my python skills! ;-)

Spa Light and Spa Temperature work perfectly!

For toggle, I am able to start each of the pumps (1-0x04, 2-0x05, 3-0x06). Small trouble that I seek to correct: 1st toggle: pump starts at high speed 2nd toggle: pump switches to low speed 3rd toggle: pump stops

…What I'm looking to have is: 1st-Low, 2nd-High, 3rd-Stop. I'm trying to figure out where in the code I can influence that!?

For pumps status, it's a bit messy! I can retrieve correct status of the Pump one with 0x03 bytes. But for Pumps two and three, nothing work. While I'm toggling Pump one at high speed, it gives me the indication that Pump 2 is running at High speed too… That is a wrong indication as pump two non even operate!

If you have any other clues, let me know! To have a print out of the data coming from the spa, what is the easiest way to retrieve that information (command on Hassbian)… It will be easy then to identify good bytes!

Again, thank-you for your involvement in that development!

(Before submit a pull, I will try to depersonalise the code by removing "bullfrog" filenames, calls, etc. as the Balboa Wi-Fi module connect/control many spa trademark. Mine is a Coast Spas.)

jmoor3 commented 5 years ago

Sending response from mobile phone so bear with me. You likely want to dig in to this function

https://github.com/jmoor3/homeassistant-components/blob/424d25042caf9b7428faee9d38c4ca03758ebb21/custom_components/spaclient.py#L186

The toggle sends two toggle messages in a row but it may assume the pump goes from Off to High to Low. Yours may be different and only need a single toggle.

As for the state showing High, that’s odd and maybe a bug. Does it go back to Off after a while? One thing that I needed to do in this code is to set the display values to the intended value and then have it update to the state the machine gives back at the next polling interval. The last four lines of this function do that and may very well be doing it wrong.

To get the information the best thing I’ve found is using LOGGER.debug liberally with variables you care about and checking in the main log file. Not ideal but works pretty well, despite having to restart after every change.

On Wed, Jan 30, 2019 at 10:01 PM plmilord notifications@github.com wrote:

Thank you very much for your advice! I'm improving gradually my python skills! ;-)

Spa Light and Spa Temperature work perfectly!

For toggle, I am able to start each of the pumps (1-0x04, 2-0x05, 3-0x06). Small trouble that I seek to correct: 1st toggle: pump starts at high speed 2nd toggle: pump switches to low speed 3rd toggle: pump stops

…What I'm looking to have is: 1st-Low, 2nd-High, 3rd-Stop. I'm trying to figure out where in the code I can influence that!?

For pumps status, it's a bit messy! I can retrieve correct status of the Pump one with 0x03 bytes. But for Pumps two and three, nothing work. While I'm toggling Pump one at high speed, it gives me the indication that Pump 2 is running at High speed too… That is a wrong indication as pump two non even operate!

If you have any other clues, let me know! To have a print out of the data coming from the spa, what is the easiest way to retrieve that information (command on Hassbian)… It will be easy then to identify good bytes!

Again, thank-you for your involvement in that development!

(Before submit a pull, I will try to depersonalise the code by removing "bullfrog" filenames, calls, etc. as the Balboa Wi-Fi module connect/control many spa trademark. Mine is a Coast Spas.)

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jmoor3/homeassistant-components/issues/5#issuecomment-459196771, or mute the thread https://github.com/notifications/unsubscribe-auth/AARkKbzppxvEgKAWnZoRE16euhLKSUmPks5vIlxugaJpZM4aUbqJ .

plmilord commented 5 years ago

Latest developments…

1-Pumps starting cycle (SOLVE) After removing the second action command at the pump, the cycle is now normal, ie: stop, slow, high, stop

2-Pumps status update to animate correctly sensors in Home Assistant Web interface (ISSUE) I validate the correct masks for pumps… Yes they are as expected. 0x03, 0x12 and 0x48 To do this validation, I used that website: http://balboahottubapi.azurewebsites.net/api/panel

For now, the set_pump function now look like:

def set_pump(self, pump_num, value):
    if pump_num == 1:
        pump_val = self.pump1
        pump_code = 0x04
    if pump_num == 2:
        pump_val = self.pump2
        pump_code = 0x05
    if pump_num == 3:
        pump_val = self.pump3
        pump_code = 0x06
    if pump_val == value:
        return
    self.send_toggle_message(pump_code)
    if pump_num == 1:
        self.pump1 = value
    elif pump_num == 2:
        self.pump2 = value
    else:
        self.pump3 = value

...With pump status array declared like this:

pump_status = byte_array[11]
self.pump1 = ("Off", "Low", "High")[pump_status & 0x03]
self.pump2 = ("Off", "Low", "High")[pump_status & 0x12]
self.pump3 = ("Off", "Low", "High")[pump_status & 0x48]

PROBLEM: when I operate pump 2 and/or pump 3, the sensors do not update (in Home Assistant Web interface). I get messages burst in Home Assistant log:

Update for switch.spa_pump_2 fails Traceback (most recent call last): File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state await self.async_device_update() File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update await self.hass.async_add_executor_job(self.update) File "/usr/lib/python3.5/asyncio/futures.py", line 380, in iter yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result raise self._exception File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run result = self.fn(*self.args, **self.kwargs) File "/home/homeassistant/.homeassistant/custom_components/switch/bullfrog.py", line 79, in update self._spa.read_all_msg() File "/home/homeassistant/.homeassistant/custom_components/spaclient.py", line 155, in read_all_msg while (self.read_msg()): File "/home/homeassistant/.homeassistant/custom_components/spaclient.py", line 150, in read_msg self.handle_status_update(chunk[3:]) File "/home/homeassistant/.homeassistant/custom_components/spaclient.py", line 66, in handle_status_update self.pump3 = ("Off", "Low", "High")[pump_status & 0x48] IndexError: tuple index out of range

When I operate pump 1, lights and temperature, everything's work perfectly… No error log!

If you have any ideas, let me know!

jmoor3 commented 5 years ago

Okay now I see the bug. My hot tub only has one pump so I’ve never used this code.

You need to shift the bits over to use this as an array index so it’s not correct as is, you can either mask and shift or shift and mask. Instead of pump_status & 0x12 you’ll want to do pump_status >> 2 & 0x03 and instead of pump_status & 0x48 you’ll want pump_status >> 4 & 0x03

On Sat, Feb 2, 2019 at 9:22 AM plmilord notifications@github.com wrote:

Latest developments…

1-Pumps starting cycle (SOLVE) After removing the second action command at the pump, the cycle is now normal, ie: stop, slow, high, stop

2-Pumps status update to animate correctly sensors in Home Assistant Web interface (ISSUE) I validate the correct masks for pumps… Yes they are as expected. 0x03, 0x12 and 0x48 To do this validation, I used that website: http://balboahottubapi.azurewebsites.net/api/panel For now, the set_pump function now look like: def set_pump(self, pump_num, value): if pump_num == 1: pump_val = self.pump1 pump_code = 0x04 if pump_num == 2: pump_val = self.pump2 pump_code = 0x05 if pump_num == 3: pump_val = self.pump3 pump_code = 0x06 if pump_val == value: return self.send_toggle_message(pump_code) if pump_num == 1: self.pump1 = value elif pump_num == 2: self.pump2 = value else: self.pump3 = value ...With pump status array declared like this:

pump_status = byte_array[11]

self.pump1 = ("Off", "Low", "High")[pump_status & 0x03]

self.pump2 = ("Off", "Low", "High")[pump_status & 0x12]

self.pump3 = ("Off", "Low", "High")[pump_status & 0x48]

===========

PROBLEM: when I operate pump 2 and/or pump 3, the sensors do not update (in Home Assistant Web interface). I get messages burst in Home Assistant log:

Update for switch.spa_pump_2 fails Traceback (most recent call last): File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state await self.async_device_update() File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update await self.hass.async_add_executor_job(self.update) File "/usr/lib/python3.5/asyncio/futures.py", line 380, in iter yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result raise self._exception File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run result = self.fn(*self.args, **self.kwargs) File "/home/homeassistant/.homeassistant/custom_components/switch/bullfrog.py", line 79, in update self._spa.read_all_msg() File "/home/homeassistant/.homeassistant/custom_components/spaclient.py", line 155, in read_all_msg while (self.read_msg()): File "/home/homeassistant/.homeassistant/custom_components/spaclient.py", line 150, in read_msg self.handle_status_update(chunk[3:]) File "/home/homeassistant/.homeassistant/custom_components/spaclient.py", line 66, in handle_status_update self.pump3 = ("Off", "Low", "High")[pump_status & 0x48] IndexError: tuple index out of range

When I operate pump 1, lights and temperature, everything's work perfectly… No error log!

If you have any ideas, let me know!

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jmoor3/homeassistant-components/issues/5#issuecomment-459968977, or mute the thread https://github.com/notifications/unsubscribe-auth/AARkKXqe5CArw4gVPJBjiUvwZKMIFpeDks5vJZ8tgaJpZM4aUbqJ .

plmilord commented 5 years ago

Hurray!

2-Pumps status update to animate correctly sensors in Home Assistant Web interface (SOLVE)

Now, everything's work without flaws... Much more better than the "bwa" app! Awesome work jmoor3!

I will submit a Pull in next days… As I said before, I will try to depersonalise the code by removing "bullfrog" filenames, calls, etc. as the Balboa Wi-Fi module connect/control many spa trademark. I will try to add two parametters in "configuration.yaml". "Nb_pump: #1, 2 or 3" and "Nb_toggle: #1 or 2". I will also review comments… Ecobee allusion in "bullfrog.py" and "light" allusion in "climate" and "switch" code.

jmoor3 commented 5 years ago

Great. One question, and something I’ve been trying to incrementally fix — does your system de sync with the hot tub over a long time period? I may build in an auto reconnect feature at some point to try to address this. Thanks for trying it out on your tub and glad it worked!

On Sun, Feb 3, 2019 at 8:28 AM plmilord notifications@github.com wrote:

Hurray!

2-Pumps status update to animate correctly sensors in Home Assistant Web interface (SOLVE)

Now, everything's work without flaws... Much more better than the "bwa" app! Awesome work jmoor3!

I will submit a Pull in next days… As I said before, I will try to depersonalise the code by removing "bullfrog" filenames, calls, etc. as the Balboa Wi-Fi module connect/control many spa trademark. I will try to add two parametters in "configuration.yaml". "Nb_pump: #1 https://github.com/jmoor3/homeassistant-components/issues/1, 2 or 3" and "Nb_toggle: #1 https://github.com/jmoor3/homeassistant-components/issues/1 or 2". I will also review comments… Ecobee allusion in "bullfrog.py" and "light" allusion in "climate" and "switch" code.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jmoor3/homeassistant-components/issues/5#issuecomment-460051785, or mute the thread https://github.com/notifications/unsubscribe-auth/AARkKUV9qX9olTShv7w0l0aVvlifnpH2ks5vJuQCgaJpZM4aUbqJ .

plmilord commented 5 years ago

Hmmm…

After 28h, I started to get this error…:

2019-02-04 17:04:29 WARNING (MainThread) [homeassistant.components.light] Updating bullfrog light took longer than the scheduled update interval 0:00:01 2019-02-04 17:04:29 WARNING (MainThread) [homeassistant.components.climate] Updating bullfrog climate took longer than the scheduled update interval 0:00:01 2019-02-04 17:04:29 WARNING (MainThread) [homeassistant.components.switch] Updating bullfrog switch took longer than the scheduled update interval 0:00:01

I have resolved this situation by rebooting the Raspberry Pi. I will continue follow the overall stability. Have you try to play with "scan_interval"? Maybe 1 sec. is a bit overkill!?

Also... As all others who use this Balboa Wifi module, after a while (~1 month), the module stop running. I plan to detect such state using the ping platform and toggle the Balboa Wifi module alimentation with a Z-Wave FortrezZ MIMOlite relay if I lost ping signal for 5 minutes.

jmoor3 commented 5 years ago

One second should be fine, that's how often the tub sends a status update. This is the issue I referenced above, the network connection goes stale, doesn't disconnect but hangs. Right now if you toggle some information like the temp it will force a reconnect because I've put that logic in. Let me dig a bit more to see if I can better detect a hung connection in the update method.

On Mon, Feb 4, 2019 at 9:10 PM plmilord notifications@github.com wrote:

Hmmm…

After 28h, I started to get this error…:

2019-02-04 17:04:29 WARNING (MainThread) [homeassistant.components.light] Updating bullfrog light took longer than the scheduled update interval 0:00:01 2019-02-04 17:04:29 WARNING (MainThread) [homeassistant.components.climate] Updating bullfrog climate took longer than the scheduled update interval 0:00:01 2019-02-04 17:04:29 WARNING (MainThread) [homeassistant.components.switch] Updating bullfrog switch took longer than the scheduled update interval 0:00:01

I have resolved this situation by rebooting the Raspberry Pi. I will continue follow the overall stability. Have you try to play with "scan_interval"? Maybe 1 sec. is a bit overkill!?

Also... As all others who use this Balboa Wifi module, after a while (~1 month), the module stop running. I plan to detect such state using the ping platform and toggle the Balboa Wifi module alimentation with a Z-Wave FortrezZ MIMOlite relay if I lost ping signal for 5 minutes.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jmoor3/homeassistant-components/issues/5#issuecomment-460487919, or mute the thread https://github.com/notifications/unsubscribe-auth/AARkKVuVXH0Zd9c-FSQ3_1fyC7Rs7ye9ks5vKOgsgaJpZM4aUbqJ .

plmilord commented 5 years ago

Since rebooted my spa, the spa client work like a charm! No more warning for many days… I still supervising that!

I did some network traffic sniffing to have a look on what can cause this warning. I will continue to do so to identify who is the malfunction initiator!