paulbates

I asked recently on the Insteon Forum, and "Insteon John" provided the schematic for the signalinc with the parts listed. I made my own. Follow this link to the Insteon forum, and scroll down to the bottom, I provide the parts list from mouser.com there. It's 2 very small parts that can go in a single gang work box on the side of the panel. An electrician can do it if you don't want to. If you have one meter then I'm guessing only 2 legs feed the house and only need to add one of these. You could try with one and see what happens. But if you choose to try, buy 2 sets of parts... the shipping is more than the parts.

From a recent discussion with yolink support about local API: " 2. We understand the importance of local API capabilities, and I'm pleased to inform you that a Local API is expected to be released by the end of this year. Waiting for the local API could indeed be a beneficial decision for your application, providing a more streamlined and responsive solution.'

No, sorry I may have said it to wrong. I was in support of your comment, and agreeing that they respond to their user base... we're all good. 👍👍

I am very impressed with the responsiveness of yosmart support. I've found a few things wrong and the app and they have acknowledge them, as well as acknowledged feature requests. I realize the path to implementation is longer, but I really appreciate not being sent generic links to generic solutions. I asked them recently and got the opposite response, there are new features but not local api for hub 3

Thanks, this explanation helps me. My first application is an 8003 TH module in the bathroom to activate a vent fan. I used the app graph and log data to determine the "slope" for humidity increase for iox programs to know it's the shower being run vs ambient humidity changes What the sensor shows, the app shows and the nodes in iox can be different things, following each other. I get that the sensor doesn't update the cloud right away, but I've been watching its operation, and I think its natural time gaps in sensor->cloud, and additional gaps cloud->plugin & iox. This is not a complaint and I don't have enough data ready right now to report. This plugin is a great thing and I have plans to expand my yolink sensor network, especially now I know what to expect.

It happened to me at my last house. In 2007 ish I bought original Insteon devices and used in x10 mode and eventually migrated. Some were re/de-programmed successfully. Some were buried, like inline lincs in the ceiling or attic and wasn't going back up there to press something to reprogram x10. Other times I got unexplained X10 in my log but given my x10 origins, I just programmed around it

Insteon devices haven't supported X10 for a number of years. See this comment from Insteon from 2016 as a point in time reference. Start with the oldest devices by model number and FW version to see what you can find.

If you look at the 2 screen shots in the Insteon forum post, those show the difference- # of hops before and after throwing the breakers for the signal linc. That was my last house where I had a number of dual bands. That screenshots are of the homeseer plugin, from homeseer that I no longer have. I don't have homeseer at the new house, but I did use the event viewer and on/off and query every Insteon powerline capable device several times after the installing the parts. Everything has 3 hops left almost every time. Maybe an audit of ~5 devices and try that yourself.. but also add any problem devices like micro module.. how many hops average?

The AC wasn't available to me at the time to report the FW versions of recent devices that "All On"-ed 2450 iolincs .41 Micro dimmer 2442-222 .49 Siren 2868-222 .46

Signal linc 2406h. It's a hard wired insteon phase coupler https://forum.insteon.com/forum/main-category/main-forum/118349-does-a-compatible-phase-coupler-still-exist

While I've not had an "all on" event, I took the challenge too see what would happen based on another thread here.. and pressed the iox "All on" button on the main view. What I observed that responded, all recent model micro dimmer alarm module 2450 / io module What did not respond: I3 paddles and outlet My installation is eisy/iox and everything is new as of last October. The light controlled by the micro dimmer started occasionally coming on randomly, every few days. I first thought it was the i3 paddle that controlled it as it always worked properly from eisy. Brightening/dimming with the i3 paddle occasionally had jumps and flickers, where 2 lights of the same brand/type connected to the i3 paddles load did not. Unrelated to this happening, I was given the parts list for the guts of the old signal linc on the Insteon forum, got them from mouser and installed. It was a few days before I noticed: that was the end of the random ons from that one micro dimmer' that was early December. The dimming isn't as exact as the load on the i3, but nobody but me would notice.

Another possibility is that the wrong port was selected to plug the cable into the acadyan. The deco's WAN port should be used to plug into an acadyan LAN port (if there more than 1). it can have yellow coloring If the wrong port was used, both DHCP servers would be active on the LAN and explain the symptoms

I asked them directly about local API recently in reference to the new hub 3 and got this response with no comment on local only support:

There's a number of moving parts here. After connecting and starting the isy, Can you look at the connected devices on the acadyan, is the isy there? Most routers have a page of connected devices and DHCP assignments Same for the deco I'd do ping tests from other connected devices and see what their subnets are and can they ping the isy Can you look at that and respond back with that info?

I recall others doing this in the past. It's not particularly pretty, but can be done... assuming the rest api has not been deprecated. You could push device states and variables back and forth with Network Resources with substitution {,,}. If the shop will not be changing frequently from a device perspective, it might be worth it. Pass variables back and forth for a few devices/functions you want to control or monitor from the main building. https://wiki.universal-devices.com/ISY_Developers:API:REST_Interface Scroll down a bit to devices and variables. I've done the variable setting from my own python programs, it does work well. Here's a related how to for zwave

One option: Is there a keypad nearby with an extra key? Pressing it could change another variable for the "business" at that time and override for x minutes Another option: is "business" at known time windows? Program exceptions for those times

I monitor 2 of 27 Insteon devices, 2450 io modules that monitor my sump pump. This post has examples of how to program it It only runs when I don't hear from one monitoring the motor running after 5 hours, so it rarely runs. Trying to do this for 25 devices will involve 26 - 50 programs, depending how you initiate the query, and will create significant Insteon traffic with messages going out and coming back to 25 devices that could collide with each other Maybe program the critical one like the fridge, scheduled to run a couple times a day(?)

The conversation will be initiated by the eisy and / or UDM app locally, outbound initiated to the portal. NAT firewall rules allow outbound and related inbound traffic, so there shouldn't be an issue. Between enhanced DNSSEC services and Trend Micro, I have network protection too and have not had UDI services blocked for the NAT firewall rule reasoning above. FWIW my router shows eisy keeping an IPV6 address open as well which I assume portal

I've never tried it, but iox has a programming step under Then statements Select System, pick Restart iox from the drop down This is addressing the symptoms but not the problem.. Its probably best to try and find what's happening when things go wrong Look at the iox and plugin logs / error logs after the event occurs Find out the unix command to track memory and process use... ssh in and observe the change in resource use over time. I've not done this with eisy / BSD, but with rpi/raspbian, I don't know these exact steps but someone here will

It was me, not UDI. I was writing a program that resulted in a tight loop with many UDM push notifications. My bad and apologies to UDI and this community Paul

I think there were migration options in the fall. I think your best bet now is to submit a ticket, explain what you have already here and ask what if anything can be done The ticket system is their way of managing work queue https://www.universal-devices.com/my-tickets/

You're welcome. Even in today's world, 1 second sounds skinny to me... lots of links in the chain / moving parts from the weather service, email, and the ISY itself. Time and use may prove this out either way.

The reason it's happening is that you want to know if either is triggering, and they both are at slightly different times. Assuming they're both triggering within 5 minutes of each other, I would do it with a timer and a second program Program freeze warning 1 If Your first weather condition Or Your second weather conditon Then Run program freeze warning 2 else Program freeze warning 2 (no if) Then wait 5 minutes Send notification 'xxx' Resource 'Freeze warning message' else When the second conditions triggers, the second program will restart because it's waiting, and you'll get only one message. Start with 5 minutes and then try reducing the wait time so there's not as much wait, but the program continues to run only once

No, by hub I mean yolink... yolink has a hub you have to use to integrate the sensors Yolink sensors -> Yolink hub -> ISY Yolink Plugin -> ISY You want the yolink hub to have good wifi and be close to your wifi router so it has good communication. The sensors can be further away. I had to send notifications, the cycle could be a very long time if the temp doesn't change, like 40mins to an hour? I haven't found a way with the plugin to access this, but that app does show last update in minutes. An ISY program could be written to track this

Hi, welcome Yes, navigating the forum can be a handful, because the ISY can do a lot. You've posted in the right location in this yolink subforum On to YoLink. I am a recent adopter too, specifically the 8003 basic temp and humidity sensors. The yolink app is an integral part of getting updates timely. I can provide bullets that I think will help: Wi-Fi and yolink radios: Yolink needs good wifi from the yolink controller to the ISY. IMO, its much more important to place the yolink hub in location that lets it get good wifi signal than worry about sensor location Yonlink sensors use a special long range radios to communicate with the hub, not wifi Long range is a relative term, but I suggest setting up as I outlined above Yolink temp/humid sensor update timing The 8003 sensors by default have a long cycle to save battery. You can affect this, using the app Find the sensor in the app, select it Click on the 3 dots on the upper right next to the sensor name pick alerts Set the temp/humidity slide controls to define normal expected temp Once the sensor crosses from normal to alert, it will update more frequently You can also set your own Alert interval at the bottom In the FAQs it discusses this a little more What I did: I have a enclosed 2nd floor laundry room, and a second floor master bath that I want to control humidity venting for Installed an Insteon i3 paddles to control the fans in each location Installed an 8003 near the switches in each location Used the yolink app history graph for each location after laundry and showers Picked alert ranges for each. Temp and humidity have lives of there own, and for the laundry room, temp was a better indicator Wrote really basic ISY programs for each that looks for => alert level I'll probably have to revisit based on seasonal relative humidity. For now, it works as desired Master Bath Fan Control - [ID 003A][Parent 0006] If 'HVAC / Master Bath Temp Humidity Sen' Current Rel Humidity (%) >= 44.0% Then Set 'HVAC / Master Bath Fan' On Else Set 'HVAC / Master Bath Fan' Off