Goose66

I thought about that, but the problem is that if a specific value was required to work, we would have to communicate with every user on how to add it to their installation, and then if the value was required to change to a different value (or, say, needed to be randomized) then we would have to both roll out a new version and communicate to every user that they needed to remove any value they currently have configured. That said, I thought I had found a way to update the value used in the Node Server Store and then have all the installed node servers pick up the value on restart, but it looks like it won't work as I expected. If that is indeed the case, I guess a Custom Configuration Parameter settable by each user might be the best available choice.

I have added User-Agent headers to both the oAuth calls and the REST API calls and it is working. I am in the east, but I’m not exactly sure how the load balancing works or if your geographical region has anything to do with. The oAuth servers are a partner company and not Chamberlain. The concern is that Chamberlain will start using the User-Agent to block particular integrations, so I am adding a facility to allow me to simply change the User-Agent value on the fly without needing a new version of the node server to be packaged and uploaded. Should be done and released in version 3.2.22 tonight.

I saw the conversation on the pymyq GitHub repository today about the changes. Unfortunately I am traveling until Wednesday, but should be able to look at it then.

Ok, let me see if it may be the phase out of older API calls. This happens every year-and-a-half or so. UPDATE: While it could be just a problem with the oAuth servers (a partner to Chamberlain), it looks to me like they have changed access parameters, either the client secret or something else. As I have mentioned, I built this integration based on another integration that exists out there that I couldn't use directly. So I have no way of hacking the mobile app to see what has changed in the authorization structure and instead will have to wait and see what others find. Unfortunately not seeing other integrations having specific issues reported yet, and my mobile app is still working. I will continue to investigate. If you don't restart the node server, your node server may continue to operate for some time. Also, merged the two threads.

To add to @tazman's guess, if this is an overhead light, then it is very likely that the 14-2 romex coming into the top of the left box is your load, and the 14-2 romex coming into the bottom of the left box is your line. But always better to check with a voltage tester. As he said, in the left-box, conenct all the whites together and connect the black from the 14-2 romex in the bottom, the black from the 14-3 romex in the bottom, and the black (line) from the switch together. Connect the red wire (load) from the switch to the black from the 14-2 romex coming from the top. In the right box you have black (line) and white (neutral) from the keypad to black and white, respectively, from the 14-3 romex. The red (traveler) for the 14-3 romex is capped in both boxes. Again, always best to test and know what your line (hot) is, but if you end up guessing wrong which 14-2 romex in the left box is the line and which is the load, it could fry your switch, but I would think the more likely result would be that neither the switch nor the keypad would operate (no LEDs illuminated or long beep), and you could turn off the breaker and swap them out.

Anybody using Martin Jerry switches/dimmer/modules? I bought a non-dimmer switch with Tasmota pre-flashed (MJ-S01) and developed node server for it, and I am thinking about expanding the node server to support additional MJ devices (3-way, dimmer, fan controller, plug-in modules, etc.) and want to know of other's experiences. I got the non-dimmer switch on Amazon for $14. A dimmer switch is $20, and rotary dimmer is $26. The Martin Jerry store on Amazon can be found here. It's shallower in the junction box than an Insteon SwitchLinc or DimmerLinc. The entire thing is plastic (no metal frame) and it's a bit cheaper feeling than Insteon switches, with an audible clunk when turning on and off. It is also a bottom-touch paddle switch to toggle the light instead of a up-on and bottom-off rocker switch, so it doesn't look and feel like Leviton Decora switches that are found in a lot of homes (including mine). All that said, they are substantially cheaper than Insteon switches and may be suitable for rooms and floors where decor (and the associated WAF) are not as much at issue. What do others think?

The node server for the Autelis Pool Control device has been migrated to PG3. Currently it only support Jandy/Zodiac Aqualink controllers. See here for details. Let me know if there is any interest in supporting work to add Pentair support here.

I'm pretty sure the OP said he was switching the 120V input to the transformer. Switching a transformer on and off rapidly can damage the transformer if it's cheap. I suggest switching the 12V down stream of the transformer. The lights can take the rapid on and off 12V - they have a solid-state power supply.

I wouldn’t worry about the Zwave switch as much as the 12v transformer.

A new version v3.1.2 is available that supports color lights. See details in the release notes: https://github.com/Goose66/NSDocs/blob/main/autelis-pg3.md. Please take special note of the requirement of deleting nodes and then restarting the node server if you are upgrading from v3.0.1.

I have released an initial version of the Autelis node server for PG3 (v3.0.1) that interfaces with Autelis Pool Control device to allow IoX to access pool controllers (only Zodiac/Jandy Aqualink currently supported). Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/autelis-pg3.md. These devices are no longer available for purchase and the website with all information (including programming to the API) has been taken down a few years ago. Also, I do not have an Autelis device (or a pool) any more, so ongoing testing and development of this node server will be challenging. However, if you currently have an Autelis Pool Control device for Aqualink Pool Controllers and want to migrate your PG2 integration to PG3, here is your chance.

A new version (v3.1.2) has been released with a couple of new features, including the ability to specify a temperature unit ("F" or "C") for reporting temperature. Release notes for the new version can be found here: https://github.com/Goose66/NSDocs/blob/main/iopool-pg3.md.

I have released an initial version of the iopool node server for PG3 (v3.0.1) that interfaces with iopool public API to allow IoX to access iopool EcO pool monitors. Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/iopool-pg3.md. There is a 1-month trial period and then the node server is $10.95 for perpetual license. While the company has said there was a one request per second limit on accessing the API, it appears that the EcO devices only update the web service once every 15 minutes, so no need for a frequent polling interval (default short poll is 60 seconds; long poll not used). There is no "connected" status, but there is a timer since the last valid measurement was retrieved, so that can be monitored to indicate a problem with the EcO device, the cloud service, the API, or your network connection.

The ability to use variables as program conditions (if statements) is very limited. Basically you can compare them to integer values and other variables.

It would be handy for node server to have a UOM that they can report in a fixed temperature unit, say Celcius, but that would get converted for display in the Admin Console to whatever "Preferred Measurement System" selected by the user in the Admin Console System Configuration.

Currently I can only add If statements testing whether a program state is "True" or "False." Thinking about the popular two-tiered programming model (trigger->conditions), it would be helpful to be able to test whether a program was running or not, i.e., Activity is "Running" or "Idle". That way, in the trigger program, say a motion sensor being switch on, if the conditions program was already running with a wait, you could test for it and not call the conditions program a second time (thus cancelling the current wait).

+1 for the order of evaluation (not, and, then or) problem, but more specifically it may be a mixture of the order of evaluation and the program re-entrant nature of the IoX programming model. Remember that each of these programs is going to get called twice as someone moves through the stairwell, once for the Hall-Up Sensor motion and once for the Hall Entry Sensor motion. In addition, the programs will both get called and sunrise and sunset each day, cancelling any running timers (and subsequent "Turn Off" commands). Here's what may be happening: 1. Hall-Up Sensor is triggered 2. Both programs run their Then branch (because of the order of evaluation problem), turn on their respective scenes, and start their respective waits. 3. Hall Entry Sensor is triggered within a few seconds the Hall-up Sensor 4. Both programs are run again, cancelling their respective waits (and subsequent Turn Off commands), and depending on whether it's day or night, one of the programs Then branch is run and the other's Else branch is run. Depending on what order things happen, that may be why the lights are being left on. Either way, this is not the behavior you are expecting, I imagine. Looking at it more broadly, you may need to rethink your approach to programming in IoX (IMO, of course). Many of these types of anomalies that arise for the event-driven and re-entrant natures of the IoX model can be avoided by having two tiers of programs, a first for testing for trigger events to execute the program(s), and another for testing for conditions for conditional execution of statements (i.e., "Then" vs. "Else" branches). So in your case, a first program (e.g. "Hallway Motion"): If ‘Hallways / Hall-Up Sensor / Hall-Up.1 Motion’ is switched On Or ‘Hallways / Hall Entry Sensor / Entry.1 Motion’ is switched On Then Run Program "Hallway Lights" (If) Else -No Actions And then a second program ("Hallway Lights"): If From Sunrise To Sunset (same day) Then Set ‘Hallways / Hall Lights Day’ on Wait 35 seconds Set ‘Hallways / Hall Lights Day’ off Else Set ‘Hallways / ‘Hall Night Lights’ on wait 20 seconds Set ‘Hallways / Hall Night Lights’ off The first program "Hallway Motion" is enabled. The second program "Hallway Lights" is disabled. What you have now is that the "Hallway Motion" program ensures that, upon motion from either sensor, the "Hallway Lights" program will be run. The "Hallway Lights" program then decides which scene to turn on based on the time of day and starts the respective wait timer. Since the "Hallway Lights" program is disabled, it will never be triggered on its own. This approach is handy in most situations where the trigger events and the conditional events are really separate things, i.e. where you have conditions that you don't want to act as triggers to the programs. In addition, if there are multiple levels of conditional statements ("nested ifs") that need to be tested, then you can add additional tiers of programs to accomplish that. Moreover, again IMO, having your programs structured this way makes them more clearly self-documenting of their intended functionality.

That is one possible solution. Or map names to indexes in custom parameters. Another solution is for the node server to somewhat arbitrarily but reproducibly map the names to index numbers (e.g., a short integer hash) and then the IoX user/administrator/programmer would just have to learn the index number through observation. Or the node server could generate these indexes into profile entries and update the profile for the node server, and then send a notification for the user to reboot IoX. These are all possibilities. The UD folks have functionality on their roadmap that could make this easier. It would allow the node server to send the state value of the last user with both an (arbitrarily assigned) index values as well as the user name from Schlage. Both would be displayed in the Admin Console. From that, the IoX user could learn what index values went with what user names, and setup programs accordingly. I think this functionality is coming in the near term, but I don't have a date yet.

In regard to comments about polling intervals and updates: there are no pushed state updates from Schlage available here - it is 100% polling. Like in MyQ and iAquaLink node server, the concern is that frequent polling using a non-public API may alert Schlage of the the use and they may make moves to cut it off. So the Schlage node server uses the same strategy as those other node servers to have active polling (short poll interval) for around five minutes when any activity is detected, and otherwise have non-active polling (long poll interval) for the periods between detected activity. Unfortunately, in the case of wanting to turn on lights or disarm alarm systems when the door is unlocked, this may not work well unless the long poll interval is set to a potentially unacceptable short duration. Setting the long poll interval to a short duration could result, however, in constant frequent polling of the Schlage cloud service, which may create other problems (such as Schlage locking us and/or the pyschlage library out). The "Force Update" is also implemented to deal with this sort of thing. Sending the "Force Update" not only results in an immediate status update request sent to Schlage (with all state values being returned to IoX regardless of change), but it puts the node server into active polling mode. So, for example, if you had a program that sensed motion in your driveway or activity at your front door, e.g., via a motion sensor or ring camera, you could have that program do a Force Update to the appropriate Schlage lock(s) putting them in active polling mode. Then, coupled with a frequent yet hopefully acceptable short polling interval of, say, 5 or 10 seconds, you could detect unlocking by a user and then disarm alarms and turn on lights in a relatively timely fashion. We will have to wait and see how the pyschlage library usage unfolds over the coming months to see what's possible here.

The challenge with the last user functionality is that the library I am using, and I believe, in fact, the non-public API that library is accessing, provides log entries with a GUID (which is a very long string of hexadecimal characters) and a name (a text string) to identify the user. It also provides a timestamp for the log entry. None of these (GUID, text string name, timestamp) are values that are supported by UD's Node Server API. It only supports integers and floating point values. In some other node servers, such as the Envisalink-DSC node server, the device (DSC Panel) provides an integer index, e.g. "02" for the last user or disarm/unlock code. That integer index can be passed to IoX as a status value for the node labeled, e.g., "Last user code" and then it's just up to the IoX administrator/programmer to know who or what that index means based on the configuration of the device itself. In the case of the Schlage locks, however, neither the GUID or the name text string can be passed to identify the last user. There are some workarounds (hacks, if you will) but these require a lot of coding and dynamic modification and frequent reloading of the "Profile," which is not an attractive option. Similarly the timestamp value is tricky to deal with. In the case of MyQ, I take the timestamp of the last action on a garage door opener and turn it into an (integer) duration in seconds since the last action. This works but generates a lot of "chatter" in the communication between the node server and IoX, which is not really desirable. It may take some time to come up with a viable strategy and implement it, unfortunately, but it is certainly on the roadmap.

@MrBill and @hart2hart Guys, let's move the discussion to the forum below in order to make the info more accessible:

This topic was create to discuss current and future functionality of the Schlage Node Server in order to pull some conversations from elsewhere on the forum into this space.

I don't know what to tell you. It's been there for a while for me: Perhaps @bmercier will come up with something this evening. Sorry for the issues.

@bmercier Uh, oh. Now it's there twice. I won't fool with it anymore.

Ok, it's there again. Let's see if it sticks this time. 😬