matapan

Instead of using a single motion sensor, you can use two for attempting to detect detection. The sequence of motion sensor triggers will provide the direction one is walking. I say "attempting" because in real life, people walk back and forth before the sensor times out for detecting the next event. You can set each motion sensor to have a short timeout cycle to address this.

I'm not in the same boat as you are. I am still using an ISY994i with a Z-Wave board. But I had a communication issue with one device and nearby devices would also not operate correctly when toggled off. The solution for me was to delete the device having communication errors and then add it back as a new device. This cleared the problems. The options to repair links or to update them were useless. It might be worth a try to delete one of the devices that you lose and add it back to see if it sticks around.

I was able to address the issue with odd behavior in the Admin UI with respect to the state reporting of Z-Wave devices recently added to my setup. The Admin UI was not correctly displaying the state information from one of two Aeotec Trisensors I added. One of the sensors would toggle on a motion sensing flag then toggle the flag off after the timeout period was reached with no additional motion sensed. The other sensor would toggle on like the first one on motion detection but would fail to toggle off on timeout. At the same time I was having this issue, one of my Z-Wave devices kept reporting communication errors. The option to repair links or update neighbors didn't do anything to resolve the communication errors. So I deleted and added the device back, then restored any links or references in programs that were broken when the device was deleted. This cured the communication error, and also corrected the state information reported in the Admin UI. For whatever reason, UDI Mobile was reporting the correct state information from both Trisensors. FWIW, this is what I found as a solution. If you have Z-Wave devices and get communication errors, don't ignore them - other devices in your Z-Wave network may be impacted if you leave the error(s) unresolved.

I have an ISY994i with version 5.3.4 firmware. I have the Z-Wave Plus board installed in the controller.

Thank you for this reference!

I recently added several more Z-Wave devices to my setup and ran across some interesting behaviors. The two Aeotec Trisensors I added behaved differently from each other if the Admin UI is assumed to be accurate with respect to device state. On motion detection, each sensor changes its motion state from off to on. Upon reaching the timeout period, only one sensor reverts back to an off state for its motion state. The other sensor remains in an On state with respect to motion detection. All of this was reported in the Admin UI. I tried modifying the parameter of the motion sensor, but upon choosing (Write Changes), the Admin UI returned a communication error for the sensor. I assumed this was due to the proximity of the sensor from nearby Z-Wave devices. For a completely different reason, I installed UD Mobile on my phone. I looked at the device state for the motion sensors and noticed that both motion sensing states were now off. I triggered each of the sensors and waited for the timeout period to be reached. In the mobile app, both sensors reverted back to an off state after the timeout period was reached. There were no communication errors. What can account for the difference in reporting from the Admin UI and UD Mobile? Why am I getting communication errors in the Admin UI with these devices but not in the mobile app?

thanks, but I still get a 404 error after modifying the url

http://10.0.xx.xx/rest/zwave/node/ZW023_1/query/

Second method is over my head.

I get a 404 error when using the first method.

I had the occasion to turn some circuit breakers on and off several times while working on installing some new outlets in my house. The circuits power cycled have some Z-Wave devices on it. Apparently, power cycling these Z-Wave devices didn't do them any good, as I am getting strange communication errors now for these devices. According to the wiki page article on communication errors, there should be an option in the Z-Wave menu in the Admin UI for healing the Z-Wave network. I cannot find this menu pick or its parent called Tools. Is the Wiki page outdated? I am on firmware version 5.3.4 on an ISY994i with the Z-Wave plus board.

I have the occasion to update device properties on two Aeotec Trisensors I acquired recently. There appears to be a means to set a device's properties by specifying a parameter to be updated along with its value in the Admin UI. There doesn't appear to be a means to view the device property values directly. I think I found another post in this forum which describes in general detail how to pull the parameter values in a script and assign it to a variable to email or text it out. Seems like a kludge if all you want to do is to see the current device property value is set to. Is there an easy way to see the parameter values set for a device? If the script route is prescribed, can someone describe in detailed terms how this is done? Thanks.

What if you deleted and recreated one of the scenes that is failing? Does this change anything?

I'm kind of curious if an extra layer of control causes noticable latency.

I second the recommendation you should just test the bulb with your specific configuration directly. There are many Insteon dimmer revisions, all addressing different issues. Some of them I recall related to specific flickering conditions. You may or may not have the revision that addresses the flickering issues. Bulbs themselves have specific characteristics that cause them to flicker on one circuit but not another. It's beyond my pay grade. I can just share with you my personal experience. I'd just go out and get the bulbs and see if they do the trick or not. If not, hopefully you've purchased them from a retailer that has a good return policy for situations like this.

The easiest solution is simply to find an Insteon motion sensor. They're available on eBay and other places online even if they're not on the Smarthome site. No repeater necessary, no protocol conversion. The other alternative might be to used a wired motion sensor attached to an IOLinc.

You can find Insteon motion sensors on eBay still. if your setup is primarily Insteon based still, using an Insteon motion sensor has its advantages. The timeout period can be set to different values. The latency of the sensor is relatively minimal. ZWave sensors are also an option, but the sensor may be affected by the number of devices on your ZWave network and where the sensor is located in relation to the ISY. I personally have on Schlage sensor which has a fixed timeout period. That can be a potential issue for certain applications. I don’t know about sensors from other companies. X10 sensors might be a low cost alternative too. The X10 signal is wireless and would require a tranceiver near the ISY.

Yes, that is the menu pick. I am not the only user who noticed nothing happens when activating this pick. Not sure why.

Selecting the menu pick does nothing, as others have pointed out. If the new way to access ISY externally is via the portal, why keep this at all?

So thank you to all who have responded.I have a portal subscription already and accessing the ISY this way is fine. One has to ask why the menu pick for managing certificates hasn't been removed from the Admin Console. It seems to serve no purpose based on the lack of functionality and rationale described here, only serving to be a potential unnecessary call or support request generator. Why not clean up the UI?

First, let me say that I have very little knowledge or understanding of web security. As a user, all I really care about is being able to access the application in question. That said, I have followed the advice regarding the use of ISY Launcher to start the Admin Console on my local area network. I wish to access the Admin Console when I am outside of my local area network.To that end, I have set up the port forwarding necessary to access the ISY externally. I obtained the IP address my home connection uses, then set up an entry in the ISY launcher to access the Admin Console externally. After successfully launching the Admin Console, I get an error saying that my security certificate is expired and I need to update it. In the AC Help dropdown, there is a menu pick for managing certificates, but it brings up nothing when invoked. Found a post from another user on this forum about the same issue with certificate management, but the ensuing discussion is over my head. What is required to access the Admin Console externally without certificate errors? Thanks.

FWIW, I wrote a test program to try email to text notifications using my T-Mobile number. It worked. I used the default SMTP settings. I did not try testing the message length, just a short text alert. If one were to try Pushover, what would the Network Resources setup look like?

Magnitude Lighting makes a line of transformers which I found works reasonably well with Insteon dimmers.

When you see this behavior, was the Admin Console idle for a while? Sometimes the Admin Console loses its connection, even if it does a refresh when you relog in. I find it best to close the Admin Console and restart it. Usually the queries will refresh correctly after that.

I've been playing with ZWave devices of late. Here are some tips: 1. If you have the means to relocate your ISY to the very center of your home, I would do this. You'll generally have more uniform coverage this way over the long run. Having the ISY located in a place with an outlet nearby that's easily accessible makes it easier to add a ZWave device. 2. It's best to add any new devices close to the ISY for the best results. You can always move the device where you want, provided it's within the range of the ISY or a repeater device. 3. Plug In devices seem to have the best range compared to devices installed in wall. 4. If the device you are attempting to manage is located in a place where the ISY cannot communicate with it, either directly or with repeater devices, add some plug in devices between the target device and the ISY to create the mesh between them. The plug in devices don't necessarily have to do anything, other than to act as repeaters. Best to make sure no one unplugs these devices any time so as not to compromise the link. 5. 500 level devices are faster in responding than the 300 level devices. If you have a latency issue where a light doesn't turn on as quickly as you want and it's a 300 level device, swap it out with a 500 or 700 level device. The latency drop is noticable.