Plugin philosophy discussion #27
Comments
|
Thanks for writing this and putting on the table a discussion on where this plugin can and should go. I would love to see the plugin further extended, and have spent some time trying to familiarize myself with the current code. The way the plugin is written is very centric to the thermostat zones and extending outside this is proving difficult for me (would be happy to have someone else look it over). My personal goals/wishlist would be to get the OAT sensor finished/working and finalize FilterMaintenance to contain filter change notifications inside HomeKit. We have humidity values captured already and I use them in regular automations myself. Other ideas would be to add a fan service?. One of the primary challenges with Homekit and Infinity are of course the limitations HK has for its thermostat service in comparison to what the Infinity does. Me personally, I have a single zone. My 2nd zone in my house actually doesn't use Infinity system at all, but does have a native HK thermostat. My personal goal is for no one in the house to have to manually touch the thermostats and that holds true for the most part. |
|
I really enjoyed extending the plug-in to add some of the features I did. Admittedly it was mostly experimentation and learning a bit of HomeBridge. I'd like to go back and refactor my changes and submit a PR for this repo. Maybe this weekend. I made more changes to the plug-in then were necessary for a PR, which was part of the reason for branching it. I like to see the discussion about the plug-in. My ultimate goal with the changes I made were for making the thermostat work well when using Siri for control since I rely mostly on HomePods. It's been a dream of mine for years now to get the Infinity stat working with the rest of my automations. |
|
I noticed you refactored the way the infinitude API is used in yours. It looks like you call the API directly instead of parsing the xml. Did you do that out of necessity for getting the schedule/next activity? |
|
@rcoletti116 the limitations of HK vs. Infinitude t-stats are something I haven't researched either. I do have an Apple Developer account, so tell me if I can help by digging up any API info etc. My Infinity system has three zones, with one main t-stat and two slaves, so I can certainly help with testing & troubleshooting. I did some playing around with @dotfortun3-code's version, and figured out how to tweak InfinitudeClient.js to update the manual temp setting instead of the schedule temp, but I couldn't figure out how to code switching the t-stat to manual/temporary override mode. I'm sure it's pretty straightforward if you know your way around js, which I don't. |
The documentation for Infinitude's API isn't that great and I was having issues getting it to write to the config for setting the temperature. I was able to get it working using the API, and updated the rest for consistency. I don't think it was a necessity, I just couldn't get it working the other way.
This shouldn't be hard to do, this was mostly how the original plugin works, it just needs some tweaking to work with schedules. I believe all that should have to be done would be adding a parameter to setTargetTemperature to pass in the intended activity and use that instead of reading it from the scheduled activity. I would prefer something like that to be a setting for the plugin as my personal preference is to have it set the scheduled temperature, so it holds that temp next time it hits that schedule, but I completely understand that it is probably not how everyone using the plugin would want it to work. Perhaps add an operation mode setting or something like: manual, hold time, or set scheduled activity |
That's a great idea. Have a config setting like "OperationType" that maybe defaults to "manual" to cause a temporary manual override (do the least invasive thing) but can be set to "schedule" to affect the current schedule setting. And a "HoldTime" setting that defaults the "otmr" time for a manual override to the next scheduled activity, or can be set to a specific timespan. I'm not sure how the HK thermostat device handles manual mode, as all I see are "off/heat/cool/auto" options. But I'm probably missing something. FWIW the way the plugin currently handles zones seems to work OK, as it creates a separate thermostat device in HK for each zone. |
That’s right, HK only allows those profiles so there won’t be 1:1 mapping with Infinity. Thus you often see creative ways in leveraging Off and Auto. So any use of manual vs schedule would be a backend homebridge things to discern which one to change and not something controllable in the Home app. |
|
I have some recent experience to report regarding problems getting either fork of this plugin to run. as well as thoughts about a possible (hopefully easy) simple status read out only plugin to use as a temporary or permanent work around. Background: Homebridge running well on a Raspberry Pi 4 with 4 plugins working (GlobalCache for old Lutron radiora lights; Davis weatherlinklive; Purpleair; and HTTP Temperature reading OAT from Infinitude as suggested on this thread). Infinitude running on another Raspberry Pi 4 reading out all config and status data in web browser. api GETs work fine for status and config. Passthrough to Carrier works fine so Infinity iOS app works fine. I am able to get api status down to Zones level (and OAT as noted above). However, I can’t get api status readout at a single zone. What I would like is rt (room temperature) from each of my 2 zones to show up on Homekit. Drilling down as far as Zones gets all zone information, but I can’t find any plugin that can parse that. So, a plugin that just parses zone status information would meet my immediate needs -- but my javascript skills are not up to writing that... Problems running either of the two Homebridge Infinitude plug ins separately or together [Infinitude running from default demon call in production mode.]: Have installed the following combinations with the indicated results, latest Homebridge and plugins as of today:
Homekit runs on iOS, shows tstats but they do not update. Everything else ok. Restart HomeKit, nothing updates, including lights. log snippet: [08/02/2021, 13:45:17] [InfinitudePlatform] Creating new thermostat in zone: upstairs Thermostat
log snippet: [08/02/2021, 13:19:48] ERROR LOADING PLUGIN homebridge-infinitude-schedules:
Runs, tstats show up in Homekit, but nothing updates. Log snippet: 08/02/2021, 13:25:34] ---
… [08/02/2021, 13:25:58] [Temperature and Humidity] Successfully got data. Temp 11.8, hum 81 |
|
@etomnash that's really a separate issue from this thread, you're having installation and/or configuration problems. It looks like your issue with homebridge-infinitude is that you have schedules defined, and your t-stat is probably in Auto mode, either of which will cause that plugin to fail. You also shouldn't try to run both homebridge-infinitude and homebridge-infinitude-schedules at the same time. |
|
Apologies. I realized after posting that I should have posted the problems as new issues. My main point got lost: given these difficulties I am looking for a light weight solution to get just rt (room temperature) from individual zones. I could use the same solution as for oat (HttpTemperature plugin or similar) but the Infinitude api does not allow drilling down to a specific zone as far as I can tell. It would be very useful to have the ability to parse the data delivered by the api call http://xx.xx.xx.xx:3000/api/status/zones I thought that this might be a reasonable "philosophical" suggestion. I will try to suggest directly to the Infinitude developer that a deeper layer of api access would be very helpful, but I think their focus is elsewhere. Thanks for pointing out that Auto mode and/or schedules causes home bridge-infinitude to fail. The problem with home bridge-infinitude-schedules seems to be that module 'hap-nodejs' is missing. I am not sure what I could be doing wrong in installation or configuration to cause that. I know not to run both forks of the plugin simultaneously but did it to see if it solved the missing module problem for home bridge-Infinitude-schedules. |
I will take a look at this and see what I can find. I noticed that periodically popping up about hap-nodejs, but I am not sure what is causing the issue. I believe it's supposed to use a globally available version but it can't seem to find it. If I add it to the package.json for the plugin, homebridge complains about it. |
I think this is because you have it required in InfinitudeThermost.js but don't include it in your dependencies. Best practice is to use the global version. Check out the main plugin and compare line 1-2 of InfinitudeThermostat.js to yours https://github.com/jimhe/homebridge-infinitude/blob/master/src/InfinitudeThermostat.js. You'll see how it invokes the hap service without including as a dependency of the plugin itself. |
I'm a programmer, but I haven't yet learned my way around the guts of homebridge and its plugins. So I'm still working on being able to be helpful in that way. Between @jimhe, @rcoletti116, and @dotfortun3-code, though, I think this plugin already has a good contributor base. But I am an electrical engineer, I have a relatively complex smart home, and I have a non-technical wife, so I feel at least moderately qualified to help think through a plugin feature set that would appeal to the broadest user base and create the fewest issues, either technically or domestically.
It seems logical to assume that the ultimate goal would be for the plugin to offer full access to the infinitude feature set--current set/actual/outdoor temps, humidity data, occupancy sensor status, read/write for multi-zone schedules, comfort profiles, manual overrides, etc.--so that homebridge would have equivalent functionality to the Carrier thermostat. But that's a lot to bite off.
IMHO, multi-zone schedules and comfort profiles should be the last things addressed in this plugin, and until they are fully addressed, they shouldn't be touched. The primary function of the plugin should mimic someone using the thermostat to manually adjust the set temp, which defaults to a temporary override of the schedule. From a programming perspective, this would at least involve, for the selected zone, setting the "currentActivity" to "manual," setting "htsp" or "clsp" to the user-selected temp, setting "hold" to "on," and setting "otmr" to the time the t-stat should return to the current schedule (either a couple of hours, or the next schedule change, or maybe a plugin config setting like "defaultHoldTimeout"). Doing it this way eliminates the plugin's sensitivity to thermostat configuration (e.g., whether or not it's in "auto" mode, has schedules defined, etc.), which makes it attractive to a broader user base and easier to support.
Thoughts?
The text was updated successfully, but these errors were encountered: