New Homebridge Plug-in via MakerAPI

Thank you for the detailed explanation - I see your point on the ranges. Fixing the first one would be great because up here the temps do go below freezing and knowing the correct temp is important for back and safety thermostats. For example I have a bathroom that runs cold, and I have a backup heater that kicks in around freezing point.

Its a hacked up standup fridge that I am running as a freezer, I have short circuited the thermostat and controlling via an IRIS outlet and an ESP8266 wifi temp sensor running @ogiewon 's ST_Anything. You are right I actually dont need a thermostat for that to flow throw to HK, I just need the temp. Its not really meant to be changed any way.

Thanks again - I was being force to go back to ST and give up HE by the family until I integrated your plugin.

@dan.t found one more issue - no matter what the state of the virtual thermostat is there is another status line in iphone that says powered off. not sure what variable you are tracking there but the Rules Machine lets you only change SetPoints and Mode.
Here is the status from HE for the device

and here is what shows up on iPhone

The "Powered Off" status refers to the thermostat's fan mode (the blower motor). If you scroll down that sheet on the iPhone, you'll see the switch for it. It is normal for it to be off, unless you've intentionally turned it on. In Hubitat, it controls the thermostatFanMode attribute.

2 Likes

thanks - cool so I could map it to the actual heater switch and it will tell its state then

I'm not sure I follow what you mean. The control for thermostatFanMode is a simple binary switch: the fan is either on or off. Well, "Powered Off" is actually auto, which means it engages when the thermostat needs it. The fan switch in HomeKit still shows "Powered Off" in this case.

Don't confuse all of this with thermostatMode, which is the "spinner" you see under the temperature setting. That's where you choose "Off," "Heat," "Cool," or "Auto." What the thermostat is actually doing (heating, cooling, etc.) is reported in the thermostatOperatingState attribute. That's shown in the "Heating to 67°" part of your screenshot.

There's not a lot of control developers have over how the Home app presents this information. I happen to like the way Apple chooses to present it, but it can be confusing. If you wish, you can "ungroup" the thermostat accessory to separate the fan as its own tile. Just scroll to the bottom of that thermostat sheet and look for Show as Separate Tiles. This choice was added in a recent update of iOS 13.

What I meant was that I can use the thermostatFanMode value to reflect the state of the real switch I am controlling via Virtual thermostat. Since VT is just a container and needs to be controlled by something else apps or rules. I am using rules to turn on / off a heater based on a temp sensor. Since this is not a real physical thermostat, that means that the real state of the switch is unknown. So what I am doing now is whenever the real switch turns on or off I reflect that in thermostatFanMode - what I find is when I set thermostatFanMode to auto it shows up as off on iphone, on shows as own. Changes from iphone are ignored, and I respond to change via the rule by setting the the state from the switch.
So if the heater is running it says "powered on" when the heater is off it says powered off. If I turn the fan flag on/off - it does nothing except update itself to show if the heater is on or off.

A switch has two states: On and Off

"Auto" has to show something, and in this context it means that thermostat controls if it is on or off. I cannot decipher if "Auto" means "On" or if "Auto" means "Off", there is no additional attribute in a thermostat that show the actual state of the fan.

Unfortunately thermostatFanMode for Virtual Thermostat doesn't have an off state - however auto is working in off as far as the iphone app goes - good enough for my usage

Just thought I would update this thread with some findings. I use an old iPad Air 2 as my homehub for remote access and I had noticed that starting with iOS13 remote accessibility was getting spotty.

I purchased an $18 lightning to ethernet adapter for my iPad and since then it has been PERFECT.

I also disabled ipv6 on the network that services my iPad which may have had something to do with it.

Since it's working though, I am hesitant to figure out which one fixed it. Just wanted to share for those with spotty remote access. Love this plugin and I think 'Home' is the best dashboard for Hubitat.

2 Likes

:sunglasses:

Also the ability to control everything via Siri on an Apple watch is an added bonus.

IMG_0330 IMG_0331 IMG_0332

1 Like

I have a question I was hoping someone might be able to offer some insight on. I have quite a few motion and contact sensors in my system. Currently, I do not have those devices on the list of devices that are being sent to homebridge via this app. While I don't NEED them to be visible in the iOS Home app, it would be occasionally useful. The reason I've held off on adding them, though, is I'm not sure if adding more devices will cause either my Hubitat or my homebridge to slow down. Hopefully this isn't a stupid question, but is there a greater strain on resources (both for Hubitat and my homebridge server) the more devices that are being sent to homebridge?

I currently have 97 devices (combination of sensors switches and thermostats) through the Maker API to Homebridge and haven’t noticed anything slowing down.

I know I’ll hit the 100 device limit soon and have to start another Maker/Homebridge instance so I too wonder how many I can keep adding until I experience slow downs.

I have approximately 225 devices running across 3 instances of homebridge and I haven’t seen any performance issues. All three instances are running on a single RPi 3B+.

1 Like

I am considering a dedicated RPi 3B+ for just running HB instead of using a shared Mac mini (it gets bogged down doing a ton of stuff for my family). Any recommended guides to start with and can I continue to use PM2?

There’s an excellent guide buried in this thread. I think it’s somewhere around post #279.

1 Like

Switched to using a RPI3+ and using SYSTEMD for continuing on reboot. I couldnt get PM2 to work w/o being logged in each time.

Hi all, I am trying to speed up my Homebridge setup - I already have my AppleTV (hub), RPI3+ and everything else on gigabit ethernet. The MakerAPI plugin is the only one I have. I saw this thread and am wondering how to implement the suggested solution: Refresh speed · Issue #1559 · nfarina/homebridge · GitHub

If anyone else has any luck in getting their Home app to update quicker, do let me know. Mine currently lags when I open it for about 2-5 seconds.

I have tried to figure this one out for a long time........
I have measured the speed of the plugin and it is not the plugin that is causing the delay. On average, the plugin provides the results back to homebridge/Homkit within 2ms. All values for all devices are cached.

I have seen the same delays as you do. I even changed the homebridge code to measure if there is a delay, but also here the processing times are fast.

I can't put my finger on where the delay occurs but it must related to either how Homekit processes the response or contacts Homebridge for updates. I have even sniffed the network traffic and saw that homebridge correctly and fast responded to the value requests, that data was send over the wire and my phone still showed "updating" for a second or two after I saw it in wireshark.

Sometimes I wonder if it has anything to do with iCloud synching.....

I wish I could tell you how to fix it but I am at the end of my ropes on that one.....

Well if the master is having the same issues then I'm satisfied with my status quo... :beers:

Agreed on suspecting that iCloud syncing or other Apple walled garden type of data transfers are most probably the culprit. Here's hoping the CES events will help Apple understand that this is a huuuge area of importance.