I’ve implemented the temperature and voltage messages. They update the appropriate zone or keypad with the info. What I have not done is implement polling for voltage, temperature. Maybe don’t need to do those as Home Assistant can request voltage/temperature when needed.
As for thermostats I’m close to done implementing the tr, ts, and TR messages. I only request thermostat info for those thermostats that have a name associated with them. i.e.: no name configured, no data requested. I think that’s a good way to reduce the number of messages back/forth.
I never checked, but assume that arming, disarming etc are all handlers already in place.
What are your thoughts regarding creating a hass component? Starting fresh or going to leverage the component which @BioSehnsucht has created to communicate with his Elk library
I’m leaving the Hass code to @BioSehnsucht. I’m spending my time, for now, adding bits to the base library. I do want to see the Hass code soon though as I want to get a system up and running.
All of the arm/disarm handlers are there and work. I believe the Hass library needs to create a service to call them.
The elk -i allows for trying out all of the messages. Start with the help command then the help <command> where the command is from the list shown in help. All the two letter command map to messages that can be sent to the panel. For the arm commands they are all under al, so help al will show you the arguments.
For example to arm the system try al 1 0 1234, where 1 is arm level 1 (away), area 1 (everything is the library is base 0 not 1, so to arm area 1 enter a 0), and code of 1234.
The other commands in elk -i are to dump internal state. So zone <2 4 8-9 will print the internal state of zones 0, 1, 2, 4, 8, and 9. That will also show you which attributes of the element that are tracked. i.e.: what is printed are all the attributes that can be used in home automation.
@gwww
An observation on 0 vs 1 based naming / indexes : The Elk itself uses a 1 based scheme, which could lead to confusion if someone is trying to figure out why Output 23 is actually activating Output 24… sure, once they figure it out once, they’ll know, and the documentation can explain it, but it’s still a bit confusing to have to always keep the difference in mind …
At least for the element.default_name() method, it might make sense to return index + 1 if index is going to remain 0-based.
In my code I actually had an ‘index’ property which was 0 based (as this made certain things easier code wise) and a ‘number’ property which was 1 based, so that I didn’t have to constantly add/subtract 1 when converting between Elk nomenclature and the more easy to code for 0 based system.
@gwww If do add a number property you don’t even have to add a variable, just
@property
def number(self):
return self.index + 1
So far the only place it impacts HASS side of things is using your existing name / default_name behavior (to avoid re-implementing it in HASS side to be 1-based). Now that you changed it to use 1-base instead of 0-base for the name, I’m not sure if there will be any other exposure on the HASS side of things for it, so may not need to add the number property/method.
Got a first pass at using your elkm1 code with my HASS code working, just the zone sensor right now (since I am both going from non-async to asyncio and my Elk library to his, stuck to what I knew would work).
Now that I’ve got that figured out I’m going to flesh out as much of the rest as I can (might run into things that aren’t yet implemented, and will just skip those things for now, and circle back around to them after getting what is implemented working). For the most part it’s a lot of find-and-replace now that I know what needs to change and how.
Only the elkm1.py and sensor/elkm1.py have had changes so far, and it will only load the sensor not the other platform “domains” in HASS. Most of the configuration options are simply ignored, only the CONF_HOST option is used at the moment. I had a complicated configuration gizmo to let people hide / skip devices they didn’t want to load into HASS (originally because a full startup on my older code would take over a minute) - it is both complicated and not very good, but it solved a problem. I will overhaul it in the future once I get the rest of the code switched to your library, but for now “everything” will be loaded into HASS (though various things disabled by default i.e. disabled zones, thermostats with invalid temp readings, etc)
Some of the differences from your example code to my HASS code is due to working with the auto-installation of requirements in HASS - you can’t import you’re requirements at the top of the file and just have them available everywhere, you have to include them inside of methods / classes. Otherwise it won’t be able to evaluate the Python file to find the REQUIREMENTS to install before running it … Others are holdovers from my old code, etc.
I was already reading it …I spotted the branch and started looking.
The “complicated gizmo to let people hide”… are you referring to the include/exclude? That’s not a bad idea. I did want to add an “autoadd” or something such as that – it would only create Hass objects for Elements that have a non-default name (that’s why I created the is_default_name() method)
Anyway, looking good! I get the hacky! Get it working then clean it up, then clean it up some more
@gwww My original code would wait for the Elk to be scanned (essentially stalling HASS startup) before proceeding, so there was no need for such discovery info. Later I put scanning in a thread and as elements in the Elk got updated, if they didn’t exist yet, a callback would be made to HASS and they would be passed in via discovery info to be created. Turns out this can fail horrible on a Pi when a separate thread is making hundreds of callbacks into HASS in a very short time … or at least, it worked fine on beefier x86 system…
I also added a “fast load” system where intermittently the state of the Elk would be written to the filesystem to be reloaded later on restart, so that automations and such would find the entities already existing after startup (rather than referring to non-existant entities until the scan progressed to them).
Having the option to include/exclude allowed for speeding up the scan time when it was a major bottleneck since non-existant or undesired devices could be skipped to some extent. Also allowed to exclude devices from HASS that really do exist, if someone had a desire to do so. So I’ll probably rework it later to still be usable, but right now that whole chunk of code / configuration is going unused.
Got ‘switch’ domain working (mostly - since gwww’s library doesn’t yet seem to do anything with TC messages that I could find, no way to detect and trigger an update in HASS when a task occurs in Elk - yet)
@gwww I feel like it would be sensible from the perspective of HASS that we add additional methods to your library, i.e. the Output class should have methods to turn the output on and off, which wrap the ...send(tn_encode(...))... for example. Otherwise I must implement some of the Elk logic in HASS. Similarly setting the temperature of a thermostat should be done via some kind of method that changes the setpoint, rather than requiring knowledge of Elk protocol to craft the proper call to ts_encode. Since I’m already familiar with the ASCII protocol I can do this, but I think it makes more sense for this functionality to be exposed via “plain english” methods rather than requiring that anyone using the library already understand the ASCII protocol.
Was setting light brightness working for anyone on the old HASS / PyElk code? I don’t actually have any PLC controllers/devices connected to my testing Elk so I never really tested it. While re-implementing that bit of code using gwww’s library I realized I might have made some lame assumptions and perhaps brightness setting never worked right?
Three helpers added for Output. turn_off, turn_on, toggle. Before I keep adding helpers, are the ones I added for Output useful and what you were thinking?
Note that what I added so far, I’m trying to “template”. For example the docstring for the helpers starts with (Helper). I did that so I can automatically scan the docstrings to add commands for elk -i
Just let me know what other helpers would be useful. I can crank them out pretty quick.
Should also note that they have not really been tested. I don’t have a test harness for them yet (which is why the (Helper) will be useful. They don’t have any logic so they should be good to go… famous last words
Others are holdovers from my old code, etc.