fisix

it looks like you might be able to link an email address to iMessage (if you're an iPhone user), so if you notify via that email address, it'll push/show up as a text on your iPhone. i don't see a great single link for instructions, but if you search on link email to iMessage, you'll see some instructions and videos and such.

quick related question. does our current texting algo use sms specifically, or possibly mms? there's a push in telecom to end sms and move to mms. so, when ATT says they're ending email to text, are they ending the service only for sms? anyway, wondering if any of the below might work going forward: Common Carrier Gateway Domains: AT&T: SMS: number@txt.att.net MMS: number@mms.att.net Verizon: SMS & MMS: number@vtext.com T-Mobile: SMS & MMS: number@tmomail.net Sprint: SMS & MMS: number@messaging.sprintpcs.com Boost Mobile: SMS: number@sms.myboostmobile.com MMS: number@myboostmobile.com Cricket Wireless: SMS: number@sms.cricketwireless.net MMS: number@mms.cricketwireless.net Virgin Mobile: SMS & MMS: number@vmobl.com ah, both sms and mms: https://www.att.com/support/article/wireless/KM1061254/

Has anyone implemented a notification process that uses the IF This Then That app/service?

hi folks, i'm fairly new to the eisy. i upgraded (seamlessly from a 994i, still in use to access an encrypted zigbee link to my power meter) to the eisy mainly because the networking portal service was ending for the 994i. i remember something about text messaging costing a lot to maintain, and making that whole process more efficient being part of the push to the new hardware. i still use the text messaging to get push notices when certain things happen around the house, but the timeliness of the sms is more miss than hit of late, both before and after the recent database server shutdown (so, i don't think my issues are related to stuff that's happened since Dec. 27 or so). also, email messaging isn't something i believe i can use or rely upon. is there a push notification mechanism that's better than legacy SMS from the eisy? maybe i need to update something post-transition that i haven't updated yet? any help or suggestions for workarounds is appreciated. lack of timely event-driven push notifications in some form or fashion is a fairly significant devaluation event for my uses.

Thanks Brian, more great info. I see a few nice looking switching 5V 2A warts that cost the same as the UD 12V one (with Prime shipping) but come with a range of additional plugs, including a 2 screw terminal plug that I can attach to any wart with the 5mm/2mm barrel plug. I'll probably go with that, just for the sameness and the additional plugs. I looked for some 12V warts with similar amenities and the normal safety features, but either they were the kind of wart that blocks other plugs or they didn't look/spec out as super sturdy.

Thanks all - great info. I guess I'll go with the 12V wall wart... I hesitate to switch up from a 5v supply - that's lasted me this long without issues (will an internal regulator be working harder/hotter with a 12V input?), but seems alright if UD suggests it.

Sorry, and one last question - the wall wart I have is a 5v 1A one that the 994i came with. Is there a way for me to purchase a new one, and/or is there perhaps a better way to power the 994i? Thanks!

Ah - appears to be a power supply issue. I have a programmable power adapter (with a range of plugs) and once I used that to power the 994i, it booted right up. Scary though. Is there a way for me to backup the firmware image as well as the user settings, in case the on board memory dies? Would I just contact UD and ask for a new SD card to be shipped to me, then rely on the user setting backup to get the insteon and the smart meter integration back up and running? Thanks!

I have my 994i hooked up to a UPS, but after a ~4 hour power outage (I was away), the 994i won't boot back into a stable state. When I power cycle it, regardless of what cables are attached (modem/network), the Power LED is almost solid blue with no other lights coming on (it's flashing at a high frequency). I haven't been able to access the device over the network. How do I proceed trouble shooting it? Does this seem like a wall wart issue (not providing enough power), or an internal storage/sd card issue? If I have a backup just prior to moving to the 5.x series of firmware, will reloading that onto a re-imaged sd card (with the most recent 4.x firmware) bring back both my insteon setup/programs and my zigbee access to my smart meter? Thanks for any help.

aww. miss Grant. hopes and dreams talk, where did they go wrong?

this is the guy i saw. this might be the talk i saw - sometimes there are breakout rooms with more demo/detailed stuff, so i'm not sure.

i found and skipped through the talk you're referring to - that's not the talk i saw. the one i saw was by a fairly clean cut guy, running the talk by himself (though he had a helper), in one of the small rooms upstairs in Paris? - different talk, different people. he had a laptop, SDR dongle, and a 2x4 with two? retrofit plastic outlet boxes and an incandescent light bulb receptacle screwed to it. there was a lamp cord and two? dual band switches wired up to the light bulb, all plugged into the wall. he ran his software on the laptop, enumerated the device(s) (just a bunch of command line text to me, similar to what was shown in the Shipley talk), and then he toggled the light on and off using his laptop. i think he talked about how useful/not useful it would be to use the technique to cause mayhem or to get access to something important... he thought the enumeration could be useful, but that the wireless range was rather poor for a safely distant enumeration process (like in a car down the street or similar). i think i remember people in the audience discussing a previous demo that failed (perhaps the Shipley talk). i don't think this guy and his work were based on Shipley's work, but i do think it was meant to show that the proof of concept was doable fairly easily. whenever i broached the subject of protocol security with the smarthome folks on Alton, it was treated dismissively, and i think they tended to make public statements to that effect. that treatment of the subject was not warranted. what i took away from the talk i saw was that the insteon protocol was inherently insecure, but that it wasn't easier to leverage into unwanted access or vandalism than someone with a rock or basic lock-picking tools... as long as you didn't allow insteon devices to turn off your security system. kinda the same thing people have learned with Alexa - don't allow Alexa to unlock a deadbolt or open a garage door if you don't want an intruder to just yell their way into your house. likewise, don't allow an insteon device state change to turn your security measures/monitoring/alerts off. anyway, i think we're future proof in terms of getting centralized control of an insteon network; even once the smarthome manufactured PLMs and hubs die out, there are inexpensive ways to hack that access back into life. it'll be interesting to see what happens to Smarlab's IP. with freedom to operate, i really think powerline and dual band devices could be a $400M market, as long as someone can make the devices less expensive and smaller without making them unreliable. securing the protocol would probably be a necessity (if getting devices in many homes is the plan), but i'd want the ability to enable backwards compatibility.

weird. i watched a demo maybe 5 years ago at DEFCON and they had free reign over an insteon network - the protocol was simple to control once the hardware to access the network was worked out. i believe they used an SDR dongle for the wireless band, but noted that it wouldn't be too difficult to create a powerline module.

1) there are no falsehoods in my post. i'm just not in the state of denial you seem to be in. 2) insteon devices were never "cheap" - how many of your friends and family have insteon devices that you haven't installed for them? the reason why that number is low or zero is because very few if any middle income consumers wanted to make the $$ investment needed to have a reasonably complete smart-controlled home based on insteon devices. compare x10 and Hue or alexa dot, google home, etc. those devices (aside from Hue) are roughly half the price of an insteon wall switch, and the Hue was an actual light fixture. 3) maybe you haven't installed insteon devices in old (1980s) housing, but the outlet boxes are shallow and the apertures for the switches themselves are narrow. an insteon switch about 0.5" shorter in depth and even just 1/4" narrower side to side would have been a huge reduction in installation woes. size always matters. i don't know why you care about zwave so much. 4) did insteon improve in quality since the purchase by the current owner (at least, current in January 2022)? no. did insteon improve in quality since 2007 or so? maybe? did they ever solve the PLM issues? not that i can tell (from posts on this and other boards). my personal PLM has improved, but i'm the one who improved it (with properly spec'd and quality caps). 5) the insteon hub and its integration with other devices has always been poor. insteon didn't adapt (meaning make purchase and installation of their devices easier) throughout any of the home assistants - they just kept selling pretty much the same old stock they had on hand; zero development of devices the new install base was looking for, and really poor advertising. in fact, insteon reduced their product line (because they ran out of old stock?) as time passed, and right at the time the market was looking for devices that pushed the edge of automated control. maybe they were trying with Nokia, but that seems more like it was a paper mache mocked-up attempt to make the company look like it was worth buying. 6) i know they had a 240v load controller - i have one, and i use it to control my ancient, inefficient pool pump. what the 240v load controller can't do is select a particular flow rate, such as what's been offered in new, much more efficient pool pumps for at least a decade now. most of the new pumps have an interface of some kind that provides for two way communication, but insteon never worked out a way to partner with any of the pool companies to get their protocol integrated with a pump, even as an after-market module. instead, insteon continued to sell fairly expensive fan links based on a fully electrical control module while even the cheapest fans in Lowes have zwave, zigbee, or some other wireless protocol built into them. management failure after management failure, vision failure after vision failure, basic business skills failure after basic business skills failure.

a company can petition for different types of bankruptcy, and a court can deny any petition. in particular, a company can petition for a chapter 11 bankruptcy or reorganization, and a court can deny the petition if the reorg plan appears deficient in some way. courts tend to be pretty lenient on how they evaluate reorg plans, but people file plans that aren't complete or are way, way too optimistic all the time, and courts shoot them down. creditors also get an opportunity to voice their opinion on the likelihood of a successful recovery to solvency... they're usually pretty negative on the outlook, but their opinions can be devastating if there's been a history of poor management and the reorg plan attempts to keep the present management in place. a chapter 7 bankruptcy (liquidation) petition can be denied for various reasons, ranging from incompetence to fraud. i'm guessing, if Smartlabs attempted and failed to successfully petition for bankruptcy a few years ago, it was a reorg chapter 11, and the plan was probably deficient on its face. from what i've read, it appears that the primary creditor was the CEO, and he wouldn't have argued against his own bankruptcy petition... but a judge isn't going to allow the CEO to give everyone a haircut on outstanding corporate debt except for the CEO (and I'm sure their plan tried to sidestep that obligation). so, after getting denied relief, the company limped along losing money on facilities rent and salaries, keeping some aspects of the business looking shiny while they looked for a buyer. due diligence or stubbornness probably killed the sale, and Smartlabs exited all further expenditures and are now using what's effectively an auctioneer to sell dead assets (an active company or "going concern" will always be worth more, but they couldn't keep a pulse going). i feel for the guy who purchased the company and tried to run it, but he ran it into the ground. they had the install base and a lot of powerline expertise... if they'd have just worked hard on making things a little smaller and cheaper and more reliable, they could have easily cornered the smarthome devices market. instead, they kept trying to force devices onto the market that people didn't want to buy, they kept making unforgivable decisions about capacitors, and they kept their prices so high that most consumers wouldn't even think of installing their products... until voice assistants came along (and they STILL didn't adapt). on top of that, whatever licensing and/or partner outreach strategy they had utterly failed. i still find it ridiculous that there was never an insteon-linked pool pump. if there's one group of people who will buy overpriced smart control of appliances, it's people with pools.

Just in case y'all haven't see this yet: https://www.insteon.com/news2022 So, they thought they'd be sold in March, and weren't. I have no idea what "the company was assigned to a financial services firm" means, but I have a fair idea what "to optimize the assets of the company" means, and I think we'd all agree that the "financial services firm" screwed the pooch on the whole "optimize" aspect.

does this still require a working insteon PLM?

all seems to be back to normal.

interesting failure mode. i knew this going in, but it's always nice to be reminded why i've coded in controls that don't rely on Alexa/networking.

Please add my PLM to the list of PLMs successfully repaired using the replacement caps (mine were from Mouser) identified in this thread. As noted above, my PLM is a V1.5 1130 PLM. I've been running for more than 2 weeks without a problem, after replacing the caps. Thanks everyone for your help and for this thread.

Another update: After replacing the caps, the PLM has been working flawlessly. Yay! Thanks again for everyone's help and commiseration.

Just an update. I went ahead and purchased the selection of caps from Mouser, and installed them in my V1.5 1130 PLM. The LED hadn't dimmed in a way that I could recognize, but given the general failure rate, I went ahead and replaced them because I'm having problems that sound a lot like PLM issues. After replacing the caps and Restoring Devices, everything is working well. I won't know for sure that it was the PLM that was the issue (and therefore needed/benefited from the cap replacement) for at least a few weeks. If the system is reliable for more than a few weeks, it'll be safe to add my PLM to the list of failed/repaired. I still have the old caps, so I guess I could try to measure their capacitance...

Alright fellas, just an update. The system went back into the mode where none of the programs that required transmissions from switches/sensor BACK to the ISY were working, AND, on top of that, I couldn't run any of the programs using the various Alexa devices around the house. Just to remind, last time, the device-->PLM programs weren't working, but I could still verbally control things through Alexa... so, it at least seemed like signals from the PLM were getting transmitted out to the devices, but signals from the devices weren't being received by the PLM. I didn't do a lot of testing this time, unfortunately, but given the info you all provided before regarding the PLM failure rates, and how old mine was, I went ahead and ordered the caps to perform a repair. I did look at the LED light, and it didn't look dim to me... but whatever. In any event, tonight I pulled the old caps, installed the new ones, and then hooked everything back up. Initially, I noted that the device-->PLM programs still weren't working, but PLM-->device controls WERE working, and now I could control devices using Alexa (meaning, I could run the "then" parts of programs and control devices). So, I thought maybe I had made some headway, but things still weren't back to normal. Finally, I again went through the Restore Devices process. The process completed with no errors, and now all the programs are working as normal... meaning that both the PLM--> devices and devices-->PLM communications appear to be working. That's great, but I'm not feeling very confident about the reliability of the system at the moment. Which is a bummer after years of it being bullet proof. So, right now I'm in testing mode. If you guys have any thoughts on what might be happening, other than the caps going bad in the PLM, I'd love to hear it. Some possibilities: 1) some other component in the PLM is going bad - it seems like this would be tied to the Rx channel, but it would be pretty far upstream because it appears to be broken for both wired and wireless Rx signals. 2) some electrical component in the ISY is going bad - this could be tied to the Rx channel from the PLM to the ISY (Maybe the daughter card in the PLM is going bad?). This could be the issue - the PLM is plugged into the wall, and the ISY is plugged into a UPS - their grounds aren't the same, so I guess there's a chance that a power surge/outage could have caused a differential voltage to build up between them, enough to damage the communication components, even if they are only linked by transformers or optoisolators. 3) some logic component in the ISY is going bad - this could be a memory issue, but it'd have to be pretty mild to basically make the state machine crap out but still allow control signals to be transmitted to devices using the GUI. 4) some device in my group of devices is somehow corrupting the communication channel. I don't know how this might happen, but from other threads it sounds like some of the Insteon devices can go bad just the PLM does and perhaps send out noise on the communication channel... which could basically fuzz the system and generate erratic behavior. Just something to mull on while I wait to see if the system falls back into non-working mode. This last time, it took 2-3 weeks for the system to die, from when I last Restored Devices. Thanks everyone.

Got it. Oh well. Just get good caps and pray. Well, and maybe a whole house surge protector or whatnot.

Mine is V1.5 1130. Which makes no sense if I interpret 1015 as the tenth week of 2015. Unless there's a time warp. And V1.5 I don't think goes back to 2011... let alone the 30th month of that year. I'm working on finding a backup. Thanks for the links!