Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load Number Not Properly Derived #2

Open
zimmra opened this issue Feb 13, 2024 · 5 comments
Open

Load Number Not Properly Derived #2

zimmra opened this issue Feb 13, 2024 · 5 comments

Comments

@zimmra
Copy link

zimmra commented Feb 13, 2024

My system derives its load numbers differently than yours. (I am running 9.4.6 on a Linux based smart host)

Without modifying the code, the state within Home Assistant was being tracked properly when controlled from Savant, but I had no control over the lights from Home Assistant.

I am not sure if this is due to me being on 9.4.x or if it is just how they do this on Linux based hosts.

My load numbers follow a pattern of 80->100->180->200->280->300->380, and so on

I had to change this function to follow that on my system

def load_state_name(self):
return 'load.' + self.address.lstrip('0') + '0000'

Changed to:

    def load_state_name(self):
        address_int = int(self.address)
        if address_int % 2 == 0:
            load_number = address_int * 50
        else:
            load_number = address_int * 50 + 30
        return f'load.{load_number}'

I don't expect you to necessarily adopt this in to your codebase - was more just documenting my findings in case somebody else wants to try this on their system.

I don't think there are enough potential Savant (Lighting)+Home Assistant users out there to warrant your code taking this in to account.

@thetoothpick
Copy link
Owner

@zimmra thanks for figuring this out, sorry for the delay responding. I'll try to get this in the main branch. I'll see if I can get the Savant version and switch behavior based on that.

@thetoothpick
Copy link
Owner

@zimmra finally getting around to this. I did some more digging and found the actual definition of how the load state numbers are derived in my version:

        function getSetStateValue(id) {
            return (service.intAddress << 16 | id - 1 & 1023).toString(16)
        }

If you have time, could you look through the Web UI source (via Chrome's inspector) for a similar function getSetStateValue? Mine was in LoadLevelService.min.js. That should give the exact formula, I suspect it's hex-based as well. Then I can add a switch in the config object for which load state "mode" to use.

@thetoothpick
Copy link
Owner

I might have figured it out, yours seems to be bit-shifted by 7 instead of 16 (and I'm assuming the Load ID is being adjusted similarly), giving something like this?

        function getSetStateValue(id) {
            return (service.intAddress << 7 | id - 1 & 127).toString(16)
        }

@thetoothpick
Copy link
Owner

@zimmra I pushed a branch that might work for you, haven't had time to test it myself though: main...light-load-state-name

@zimmra
Copy link
Author

zimmra commented May 6, 2024

I might have figured it out, yours seems to be bit-shifted by 7 instead of 16 (and I'm assuming the Load ID is being adjusted similarly), giving something like this?

        function getSetStateValue(id) {
            return (service.intAddress << 7 | id - 1 & 127).toString(16)
        }

You were on the right track. Here is what I see in my LoadLevelService.min.js

            getSetStateValue: function(e) {
                return (u.intAddress << 7 | e - 1 & 15).toString(16)
            },

@zimmra I pushed a branch that might work for you, haven't had time to test it myself though: main...light-load-state-name

Very cool! I'm hesitant to change my modifications on my active/live system because it's been working well for me, but I'll be able to spin up a second development HA instance and give this a whirl - should be able to sometime this week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants