Goose66

My Schlage node server is currently working. Just restarted to verify. Please send a log package.

That’s pretty straightforward. It should restart the BPUP listener thread, however. I believe it does it in the next longpoll? I will look into it when I return to the U.S. in a couple of weeks.

Schlage Encode locks gave a node server but I don’t know if they make a fingerprint version.

Must be a first time upgraded. When you upgrade IoX, you have to clear your Java app cache before restarting IoX Launcher.

Plus a rotary dial for i3, right?

What I really want is something Leviton-like with a high-end feel, good node server (now “plugin”) support for my Polisy, preferably Wi-fi based, that supports real-time state updates now, e.g., MQTT, and will support Matter in the future with a firmware upgrade. Currently I have some Tasmota switches from Martin Jerry on one floor. They are inexpensive, but look and feel a little cheap, and because Tasmota is a “try to be everything to everybody” kind of firmware, each different type of Tasmota switch requires a little tweaking to make it work like IoX expects, and the configuration is done on a per switch basis. They are wi-fi and rock solid in operation once installed and communicating with the IoX Tasmota Plugin. I am also playing with some Shelly modules on my main floor. They are installed in the j-box in a 3-way configuration with the existing switch (Leviton Decora, in my case) so you need room in your j-boxes. These can be flashed with Tasmota for support with the Tasmota Pligin now, and I am looking into developing a Shelly-specific Plugin that could give much more native-like support to IoX with not only basic control and state, but configuration right in the Admin Console (fingers crossed). One thing that I do like about Insteon is its ability to add instant links between switches, keypads, and devices without needing IoX or other hub/controller in the mix. Some of this can be done in Tasmota and maybe Shelly, but it was easy to do in Insteon and seemed rock-solid in operation, even when communications from IoX through the PLM were flaky.

I moved 14 months ago from a house that’s was almost all Insteon (switchlincs, keypadlincs, lamplincs, iolincs, in-line modules, thermostats, leak sensors, and IRLinc… that’s all I can remember). But I could not justify putting Insteon in my new townhome. Newco has a little better track record now than when I moved, but the protocol is closed and completely proprietary, and if they fold (again) you’re stuck with what you have. I have a variety of devices now —including some old Insteon that moved with me — because I do a lot of home automation testing and programming, but if I were just looking for a whole house system, I would want wi-fi connected switches and modules with updateable firmware, MQTT support, and future Matter compatibility. You may have to wait just a little longer to get a solid high-end switch with these capabilities, but it should be worth the wait. If you are building in the U.S. right now, the one thing I recommend is deep j-boxes!

Here's something to try: using curl try posting to each thermostat with temperature values in floating point format, i.e. instead of "71", try "71.0". I am wondering if that works for ColorTouch but not Explorer.

Nevermind. I didn’t read thoroughly.

The BPUP_Listener is run on a separate thread and opens the socket to listen for BPUP events. If that thread is dying for some reason, that may be the problem. Mine has been running for months, however, and the thread stays up.

+1 for what @Techman said. Also, can you just turn off the basement light at 9:00 pm? In other words, why check if it is on first?

Two things: 1. This sub-forum is specifically for the Tasmota Node Server. The Tasmota Node Server supports a specific list of devices running Tasmota (primarily from Martin Jerry) that fall into several broad categories: Switch, Plug-in Module, Dimmer, Fan Controller, and Humidity Switch. I hope to add new device support for devices falling into these categories and new categories as we go, but this node server is not intended to support generic Tasmota devices with custom states or properties. For that, I suggest trying the generic MQTT node server that is available in the Node Server Store. 2. For Tasmota community support - particularly rules - I suggest the "Tasmota" server on Discord. There is a specific channel for discussions regarding Rules.

The Bond node server relies on two mechanisms for state updates. The first is polling the Bond Bridge via a REST API every shortPoll interval (the node server also uses the REST API to execute commands). The second is a UDP socket connection over which the Bond Bridge streams events in real-time. Bond refers to the UDP socket connection mechanism as "BPUP." When you execute a command on a device connected to a Bond Bridge, the corresponding change(s) in state for the device should be streamed back to the node server via BPUP and your IoX should update in real-time. If this is not happening for you, then something is wrong with the node server on your platform and we need to debug what's going on. I will need log file package from the node server in DEBUG-level logging and containing a restart of the node server in order to determine why BPUP doesn't seem to be working for you.

The order page says 2-3 weeks.

The ratgdo does connect to Wifi, but it is actually the ratgdo that connects to the Polisy's or eISY's MQTT broker. So as long as there is TCP/IP connectivity between the ratgdo and the Polisy, it would work (even if not on the same LAN segment). You configure the IP address or .local name of the Polisy/eISY into the ratgdo. The node server simply connects to the MQTT broker on localhost. The node server would probably have the ability to connect to some external MQTT broker, however, for advanced configurations, just like my Tasmota node server does.

I don't see motion as a state (unless you mean door motion). I see availability state: Online and Offline (MQTT LWT), door state: Open, Close, Opening, Closing; obstruction state: Obstructed and Clear; light state: On and Off; lockout state: Locked and Unlocked; door command: Open and Close; light command: On and Off; and lockout command: Lock and Unlock. Another thing to note here is, while Chamberlain may not like having this third-party device being able to control the door locally, it is doing so using PWM over the control line and emulating one of their wall control keypads, so there's no way they can push out new firmware to block access.

if I can make a ratgdo node server that basic mirrors the current MyQ node server profile (interface), it should be easy enough just to plug-in to your current programs and scenes and such.

Local. The ratgdo uses (among other options) MQTT. There is an MQTT broker on the Polisy/eISY that you would connect it to, and the node server would use the same MQTT broker to control and receive status updates from the ratgdo. Updates would be near realtime (unlike the polling of MyQ) and could be used to control lights and such, and probably more appropriately reflect "opening" and "closing" statuses and report obstructions. But yes, on backorder. Just ordered one and my friend did too (we are together on vacation at the moment).

The ratgdo looks the most promising. I would love to get one and write a node server for it, but I have Genie GDOs with the MyQ Universal Controller and Door Sensors, so I don't really have a testbed for it. I have a friend with MyQ GDOs that's buying one, but he's ditching UD to go with HomeAssistant. Maybe I can convince him to keep his Polisy running long enough to test the ratgdo node server.

This effort to block unauthorized access is only a year or less after they rolled out the public API to their "trusted partners." I suspect that none of the technical reasons the CTO would give you for blocking unauthorized access would be valid, and that the real reason is they want to make 3rd-party access exclusive to their partners. This leads me to believe that being a "trusted partner" comes with a financial cost. Now, I can't see any way that this could represent a significant amount of revenue to Chamberlain. It just doesn't make sense that HA integrators would pay enough money to Chamberlain for access that it would even pay for the efforts to block unauthorized access. If anything, you would think the result would be that Chamberlain GDOs (their primary and significant source of revenue) would just be less attractive to some purchasers, even if only to the "small percentage of users" that's mentioned in the Chamberlain letter. In my 20+ years of experience with helping companies license their IP and create new revenue streams, the ones that have tried to monetize their non-strategic IP portfolios are rarely successful. The likes of IBM, AT&T, Microsoft, and Intellectual Ventures aside, for most companies it really comes down to staying in your lane and just staying out front of your competitors in your primary market(s). So my questions for the CTO (which I am sure he wouldn't answer) are 1) what are the real reasons and concerns for blocking third-party access, and will he give us the opportunity to address and mitigate them, and 2) why not respond to Michel's requests to be a "trusted partner," even if just to say "f' off." Seems to me all they have to lose is an increase in product sales, even if it is marginally small and insignificant. EDIT: Also, a lot if not most people end up moving and inheriting whatever GDOs the builder originally installed in their home. If Chamberlain wants to open up a new revenue stream, I think a $75 gateway that allows "trusted partner" HA integrators to access their GDOs through the public API would be a much better revenue generator than a pay-to-play partner program, and would be much more inline with their primary market as a hardware OEM then that of some kind of SaS provider.

Actually, you said the setpoints update temporarily in the Admin Console, but then go back on the next poll, so I assume you won't find the "Error message returned from control API" messages in your logs. Also, I notice that the setpoints in the second query after the POST in your curl test don't match the setpoint values actually set in the POST. Are you sure you are POSTing to the same thermostat that you are querying and not the ColorTouch thermostat (stupid question but I had to ask)? Is it possible that the Explorer has screen lock set requiring a PIN to change the settings?

Addressing the two problems separately: 1. Schedule mode reporting: the API documentation says the schedpart will be 255 when schedule mode is inactive, and that's what the ColorTouch reports. The ColorTouch was the thermostat I had at hand when coding this node server, so I just used schedpart to determine the schedule setting - kind of a shortcut. Obviously, the Explorer does not report the same way, so I need to go back and look at the schedule state and the schedpart to report the schedule status values to IoX - should be an easy fix. 2. Temp setpoints: The API documentation sort of alludes to a requirement that you have to send all four settings in the settings POST (like you do in your curl test), but the ColorTouch didn't enforce any such requirement. Accordingly, the node server only sends the settings that are changing (after testing modes and setpoint deltas). That may be why the Explorer is not accepting the setpoint changes from the node server. The REST API will report success but put an error message in the return data if the POST command is not successful. Look in the node server log and do a search for "Error message returned from control API" (or some part thereof) and see if you see any messages. Or better yet, send a copy of the logs and I can take a look. If that turns out to be the problem, that would be an easy fix too.

Same with Honeywell Home - they change the active room based on occupancy (motion) sensors. But none of the node servers that I can see allow the ISY to set the active room programatically.

He wants to be able to programmatically set the remote sensor that is controlling the thermostat. E.g., if motion in basement office, set basement office as controlling sensor, otherwise set main floor as controlling sensor.

Looking at the Honeywell Home (Resideo) API, it does appear, however, that the API would support changing of rooms. The plug-in could perhaps be modified to allow changing of the priority room (along with changing the priority type to "Pick a room"). However, I don't believe the original develop is around, and the current version that Bob put out was for conversion to PG3 only.