I spent a while doing driver builds for all my Third Reality stuff. I think I took it really far and dialed them in nicely. They are heavily reliant on AI during design FWTW. Is there any desire for Third Reality drivers? I know they do generics so there isn't a huge need but I wanted all the extra stuff to work right. For instance my Temp/Humidity sensors with LCD displays are writable ie; you can tweak the display to match your offsets... stuff like that. My Plug driver is smart -it can deduce power meter capable and adjusts itself accordingly so one driver to do all 4 versions of the Plugs. I also did the night lit to get that spamminess out. I also put in true health checks where possible.
I'm running about 40 devices from Third reality so it made sense for me. Let me know please if there is interest.
Yes. I am very much interested. Where can I find these drivers? Thank you!
I'll look into using HPM. I"ve never created a bundle of drivers before, just individual drivers and apps so HPM will need to wait.
For now, if you're comfortable (please let me know if you're not) here are the direct links to each of them:
Third Reality Contact Sensor
Third Reality Motion Sensor
Third Reality RGB Night Light w/Motion
Third Reality Plug/Outlet (supports both Power Meter and Non Power Meter capable units)
Third Reality Temp/Humidity Sensors with LCD Display
Third Reality Temp/Humidity Sensor without LCD Display
In overly simple terms - you open the For Developer section on your hub, select Drivers, then add driver and either Import the link or download the code first and copy/paste it and save.
I will try and learn how to bundle a set of drivers to deliver as a group or set on HPM - seems like the proper way to make this available.
I do not use HPM, so this is perfect! I downloaded your driver, installed it, and it is working perfectly. Thank you for providing this and making it available!
I did get it up into HPM as well>
Curious if you dont' mind me asking but which driver was of interest?
I purchased four THIRDREALITY Smart Plug Gen3 Model: 3RSP02064Z and am now using your driver Third Reality Plug/Outlet (supports both Power Meter and Non Power Meter capable units)
What would be the advantage of using your drivers instead of the generic drivers that seem to be working okay. I have a number of Third Reality devices, from motion sensors to plugs to Smart Switches. Is there lower overhead with your drivers?
Anything for Smart Presence Sensor R3?
3RPL01084Z
Tired of this:
org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_openai_v0_19_THIRDREALITY_Smart_Presence_Sensor_R3_2509.deviceHealthCheck() is applicable for argument types: () values: [] (method deviceHealthCheck)
and the other log for where it blinks too much (past its hardcoded limit)
Unsure on the PIR - I don't use them - I use 2 or 3 cheap motion sensors in a zone motion - its holding the fort. you may look at @kkossev as he's the master driver person.
Not to dive too deeply - On the plugs - what started me on Third Reality (3R as I call it in shorthand) was the generic driver wasn't picking up my power capable units originally. It evolved over time as a looked into some nuances as a gen 1 and gen 2 showed up in my devices, unbeknownst to me initially.
I also have a huge problem with using the word Ping. I'm a networking person and ping always meant icmp echo. I felt the ping stuff really didn't give me any value and I wrote a really serious 'Health Check' to replace it. I have two monitoring systems for dead devices and I go days without touching some devices or hearing from them - like outlets in the Garage or backyard for example. Somehow they would show up in my Inactivity report - so I wanted that addressed.
I also like details clean. Device Data should show truth, not made up stuff that doesn't fit a mold.(IMHO). Firmware, Manufacturer, Models - I want all of my devices to show me usable data - so I approached that issue as well.
I have a standardized routine set for all the logging. I also have a routine for sendIfChanged that I've been working hard on, which cuts out (not down, Out) redundant log entries, a sort of deduplication function.
I get confused by Power and Energy. I wanted a text value to show the Unit so I could 'at a glance' see which was what (Easy to tell kWh from A 
) .
I know that OTA Firmware from Hubitat is about all there is currently. Sort of like Peter Norton tried back in '81, with the driver database debacle. I wanted Update Firmware to be a standard button on the device GUI, even if it currently didn't get anything back at least it would tell me that HE doesn't currently provide it - as opposed to not having the option at all.
I like the ability to blow away the device values with a reset, instead of having to load 'Device' as a driver, push 5 buttons, the go load the driver back and initialize.
I really want my Schedulers for polling to be functional and bullet proof. I hate when I get red errors in my logs.
And I wanted Toggle. Some drivers have it, some don't. I like to hit toggle through apps (I'm weaning off rules and writing custom apps now) so it was a must have. Honestly, My hub performance used to be 16% for the 15Min load. Now it's 6.0%. I've cut the fat as they say.
And the Commands page:
After I worked really hard on this, I moved on to the Motion Sensors, and that led me to do the contact sensors, and finally the Temp/Humidity. The api for the Third Reality is super well documented and the generic drivers work -but they don't always use the native methods, which I think are more robust. Turn on the Trace and Debug and watch my driver do its thing. I'ts really cool! I haven't work this long and hard on anything in a while - so I guess I'm will say I'm proud of the results. Are custom drivers better than generic? I think so, but I'm probably not a typical user!
I am currently using the Tuya Temperature Humidity Illuminance LCD Display with a Clock driver for my 3 Third Reality temperature and humidity sensors. My sensors don't have displays, but these Tuya drivers do work for them. Can you please share some info on your driver for these? What do yours do differently that may be better?
I've not used the Tuya driver you speak of - but if I recall correctly that comes from one of the most talented folks around here - @kkossev. I'm grateful to him for a lot of things and I know how diligent his work is - I wouldn't begin to compare.
I will say tho his approach is more provative in that he handles numerous fingerprints in a single driver.
My driver takes a different approach - more distinctly targeted. Thats about all I can say as a comparison.
I can tell you about my work and intent.
I had wanted to be very specific to use the best possible communication to devices - The Third Reality stuff does have extended features and I implemented them.
I wanted to be sure that the Battery stuff was as well built as I could possible make it and I spent a lot of time reviewing the HA and Zigbee2MQTT drivers that were recently published to get as accurate a battery as I could. My battery percentage values DID change once I changed from the Generic drivers I was using before. Time will tell if the accuracy pays off, but I trust it more now than I used to!
There were some boundary issues I discovered for the offsets, so I setup guards for that. And again, I built in extensive trace and debug as well as optimization of sendEvent to reduce duplication. The work I did on Health Check I ported here as well to replace the weak misnomer Ping that is provided in generic drivers.
This particular driver is very generic, but I did add Units for a text attribute so it can be easily added to dashboards and notification rules. It's brother, the LCD capable driver, is much more! it's actually a bi-directional driver that can change the display on the LCD - extended 3R commands you don't find generally in Tuya or Generic drivers. Oh - and the Reset Driver - I'm starting to love this - it was original just for dev work but I've grown to love it overall and am leaving it in nowadays.
Released a minor update but want to verbalize it - HPM doesn't offer a new driver added to a package after you've already installed a package.
This is a bit hard to describe! I added the Third Reality RGBW bulb to the Third Reality Drivers (Custom) package. You will see an update available but it won't by default offer you the new RGBW bulb. You need to use Modify inside HPM, choose this package, then add your selection of the bulb.
The other 1/2 this update is optimizations to the Health Checks.
Shu
@jshimota I have a few of the 3R model 3RDS17BZ contact sensors that I would like to "reverse" the open/close response.
IE when the "door" is open, the sensor reports closed and visaversa.....
Also, one of my sensors reports 80% battery (when it is at 100), and the other reports 80%, 34%, 80%,.... it keeps alternating, but I know the battery is at 100%.
Frustrating to see this, but I just ignore it.
They are running 1233-D3A2-0000003F fw (only one sensor is reporting this though?!?!?).
Any ideas on how to correct this?
Ah. the old 'contact is open when the door is closed' problem. It's a really uncomfortable place for me. I wrote something years ago for a reversed switch and what a slippery slope that got to be. You're forewarned!
My suggestion is to use an app to create a mirror and monitor the Mirror. If I recall it creates a virtual device that flips opposite of what you give it. Maybe you can make that work? If your like me and hate extraneous switches just to deal with one problem - I do get that.
Here is a driver you could use - You get to be the test case. I won't roll this up into the existing driver until you sign off. So for now, use 'add driver' and manual paste or import the URL. Then assign it to your device - and use the 'reset device' button which will clear all states. Once you implement, save preferences. and then FLIP THE PREFERENCE SWITCH! and save preferences again. After refreshing your browser the contact image in the device list should be in 'opposite day'.
THANK YOU!!! I'll give it a whirl and report back!
As to the battery. are you certain you're on 1.6.3? If you go into the Drivers section, locate the 3r contact (custom) and open it. in the changelog and static string it should reflect this. The battery area was a very carefully crafted section and I can't think of what to do to reproduce.
No doubt you've already tried this - but yank the batteries and put in different ones. Does it still flounder as you describe? Make sure to push reset device, then 'save' in preferences - then go back into the device and run configure. Maybe it is a legacy issue thats just not yet solved for you. I have 4 of these units, and none give issue. Be SURE you run the HPM update and are at the latest okay? I'l watch the board for your results.
I don't know why but I am using Tuya Contact Sensor+ with healthStatus driver for Hubitat by kkossev?!?!?! Don't know why I switched, but I think it was suggested to use it, plus I modified the driver to switch the open/close.
I will give your test case a try though!
Well I changed to your test driver and the inversion works
BUT
The battery STILL reports 38%!
Here is the debug log:
2026-09-11 18:29:59.988
debug
Ingl Nrth shade contact: parseBattery(): Computed battery percentage -> 38%
**dev:3997**2026-09-11 18:29:59.987
debug
Ingl Nrth shade contact: parseBattery(): Raw hex -> 4C
**dev:3997**2026-09-11 18:29:59.986
debug
Ingl Nrth shade contact: Processing battery percentage attribute (0x0021)
I did measure the voltage and it is 3.0 volts steady!
I ran the update firmware because THAT sensor was on the OLD VERSION!!!!
I thought I had already update the FW on that sensor, but I guess I did not.
NOW it reports 100% battery!!!!!
AND your modified driver works GREAT!
WOW.... it's hell getting OLD! hehe
Thank you for your help. I think I am good now... FINALLY!