DCardellini01 Posted January 27, 2019 Posted January 27, 2019 8 hours ago, KSchex said: Yes it does not match the Fortrezz spec sheet. I found that I had to use .8V to 2 volts input, This seemed to be the closest reasonably linear segment, not enough range. I considered doing curve segment breakpoints with a look up table or a curve fit but that was beyond the ISY. My solution was to use the MIMO2+ inputs for contact inputs from switches. I wound up with a Beaglebone black, and an 12-bit A/d to measure my house current. It sends Rest commands to the ISY setting the appropriate variables with the current (amps). Good luck.. I tried to characterize the input, with no success. That funkiness around 0.6-0.8 volts and "log-like" curve below suggests some type of diode coupling in the input circuit. I have requested input signal circuit details from Fortrezz and will report back here if they answer. But it does look like a simple dry-contact closure between sig input and common is a stable digital input setup. Is that how you are using those MIMO2+ inputs? *************** But I am just so fed up with lack of a decent analog input for either Z-Wave or Insteon platforms. DIY is crippled with expensive interfaces on both platforms. I guess I am ready to make the same plunge you have made. Want to learn more, and hoping to hop onto your learning curve. Curious on your decision for a Beagle Black. Seems like overkill for getting two CT's into an ISY. Size, power (and a bit on cost). Why not something like this: https://www.adafruit.com/product/3010 Assume you are biasing the CT and sampling the AC signal. Are you doing a simple peak detect and multiplying by a constant for RMS? Sample rate? As I mentioned in an earlier post, I am not sure wifi is my best choice for an internal sensor network. I need two access points for full coverage of my house, and I have not been successful with setting up one network SSID and having smooth handoff of cell phones and laptops. I have two separate SSID's, and that will create complication for a sensor platform. I am more inclined to use an RFM69HCW as I am confident that I can get the reach through walls/ceilings at a much lower RF frequency. Probably something like this: https://www.adafruit.com/product/3176 Opens the door to battery-based temperature sensors and clever low-power sleep programming. I would tie these RFM -based sensors back to a Beagle or Pi with an RFM transceiver, wifi, and ethernet (to the ISY). At that point, the Beagle/Pi is sitting right next to the ISY. Keep thinking I want to do my "programs" in C++ in that Beagle/Pi instead of the limited programming environment in ISY. Would be great to host a web server with some fantastic web-based graphing applet and custom SCADA screens. (perhaps I have not investigated ISY platform enough for these chores). Also, why Beagle over Pi for you? Thanks in advance for your thoughts!
KSchex Posted January 27, 2019 Posted January 27, 2019 Hi dcard..The Home Automation area is not at all like the industrial automation I am use to. Where if something fails or does not work as described there is a finite reason. A reboot or reinstall is not an acceptable fix. This just means I cannot trust my system. It will fail again. My original foray into data collection was 8051's on a 485 com line. Then 8051 with ethernet. All were my designs written in assembly & C. At retirement I decided to learn about something new and picked the Beagle because it was built well and not widely used like the Pi. It was to be a challenge to learn the hardware and Linux (and it has been). As far as hardware interface for CT's I use an AD736 and what ever is in my junk box; LM224, 308, 311, 741, 324...The A/D is a MAX172. These are all old discrete parts but real design is fun. I am not looking for speed. This Beagle monitors temp, voltage and power then reports back any change in the house 240V feed. All of my "devices" talk over their own hardwire LAN, no WIFI. There are other devices out there that could do this for less than $250, but the best part is I control the hardware and software. All device data including ISY is collected through JavaScript programming and Apache server. My ISY mainly does open/close detection of doors and gates as well as light control and audible alarm annunciation along with text messages. By the way, I use the MIMO2+ to drive mechanically latching relays (P&B/Tyco) for my exterior flood lights. One input tells me if the circuit is on/off the other tells me the status of the relay pair. ISY software is used to select the appropriate relay depending on the state. Unfortunately the antique relay control is a hold over from my early days of X-10. Any input, comments, pointers or welcome.
DCardellini01 Posted January 28, 2019 Posted January 28, 2019 Sounds like we have similar stories. Intel 8048, 8051, 8085 with assembly, PLM-88, RTOS iRMX-88, ICE emulators and 8" floppy drives. And a good dose of DEC PDP-11 for machine control (Kodak). Don't get me started on the "unspoken acceptance" of software/hardware bugs. In my day, ANY software/hardware had to buzz along 24/7 for years without crash (short of outright hardware failure). And further: the bar has lowered so much for those who design hardware and software, and that has NOT been good for anyone. The quality of software, the acceptance that Internet updates for bugs and poorly designed UI substitute for well-thought out designs is discouraging. Not a day goes by without me shaking my head about the latest forced update of some piece of software that takes a step backwards in intuitive use and elimination of important features. It just used to be that only a certain type of person got into this field. Now, anyone can claim to do it....and it shows. Especially in this consumer space of the IoT. But enough rant! So you are running Apache on that Beagle Board? Are you serving up web pages from that server? Custom screens? Are you doing any "program logic" in that Javascript, replacing what you could be doing in the ISY? I do believe that running a linux-based system is a timeless, solid strategy, even for real-time machine control (without RT extensions, solid 5msec cycle times) . And that is even with a web-server concurrently running and serving up high-performance updating SCADA screens. But I do think there is a place for a very-low-power, lightweight hardware implementation of sensor/output devices devoid of most operating system features. Great to see you are still at it!!!
KSchex Posted January 30, 2019 Posted January 30, 2019 DCARD...Spent almost a lifetime with PDP-8, PDP-11, LSI-11 and then VAX. My company originally used PDP-11/34's and 35's for the control system, having only 128K words of memory. Color graphic displays were with Aydin video controllers. The system controlled a pipeline, calculated flows, did leak detection, other system interface, and had a graphic interface all in realtime. All "determination" type logic in my system is done in the ISY. It is the most reliable part. Any required data from the Beagles is sent to the ISY as well as Apache. All display comes from Apache running on an old Windows computer. Everything is written around Apache in C, cURL, JavaScript, and a little PHP. For display I grab data from the ISY and Beagles with Apache and serve up a web page. Any "real time" alarms are done through my own audible annunciators (Zwave) and text messages from the ISY. I like the idea of low power and strive for it but my junk box parts do not always lend to it.
DCardellini01 Posted January 30, 2019 Posted January 30, 2019 Yeah! 128K would have been MOS memory. My use was 16k Core Memory (rings and wires). Use the "11" front switches to load in a machine sequence to load application program from punched tape. Wow. Times have changed. Your current config sounds like a great setup. When you were doing RS485 work, did you raw dog it, or layer in Modbus? I still think that RS485 could play a role in a low power (modular-expandable) setup.
KSchex Posted February 3, 2019 Posted February 3, 2019 On 1/30/2019 at 5:27 PM, dcard said: Yeah! 128K would have been MOS memory. My use was 16k Core Memory (rings and wires). Use the "11" front switches to load in a machine sequence to load application program from punched tape. Wow. Times have changed. Your current config sounds like a great setup. When you were doing RS485 work, did you raw dog it, or layer in Modbus? I still think that RS485 could play a role in a low power (modular-expandable) setup. Modbus would have been nice but simple was the order of the day. 485 was serial byte string address,8 contact inputs, x analog inputs, data length, CRC, binary packed data. Spoke too soon on ISY reliability. It "hung" twice in the last week and came back to life.
Michel Kohanim Posted February 3, 2019 Posted February 3, 2019 @KSchex, Please be more specific on the "hung". Error log would be great. With kind regards, Michel
DCardellini01 Posted February 3, 2019 Posted February 3, 2019 17 hours ago, KSchex said: Modbus would have been nice but simple was the order of the day. 485 was serial byte string address,8 contact inputs, x analog inputs, data length, CRC, binary packed data. Spoke too soon on ISY reliability. It "hung" twice in the last week and came back to life. I am on 9 years with an ISY-99i and then an ISY-994i Pro with z-Wave (isy-99 still operational). Never a failure with nonstop use. After I mentioned no failures on this thread (about PLM failures), I lost a PLM for the very first time. It looked like an ISY failure, but it was the PLM that went south. Michel to a quick rescue when I had a minor problem restoring to my old, operational PLM I had used with the ISY-99. Moral of the story: "Don't boast online about lack of failures." 1
KSchex Posted February 5, 2019 Posted February 5, 2019 On 2/3/2019 at 3:35 PM, Michel Kohanim said: @KSchex, Please be more specific on the "hung". Error log would be great. With kind regards, Michel Hi Michel. I have had at least three instances, that I know of, over the last month that the ISY has stopped processing commands. I wanted to try to get more of a handle on it before I asked for assistance. Unfortunately I failed to collect the log. The last time it occurred an LED was suppose to illuminate on two Homeseer WD200+ dimmers and an audible driven by a MIMO Lite was suppose to sound when a specific gate opened (Aeotec Door/Window sensor). This is all program driven and very reliable. The gate opened nothing happened. I immediately went to the admin console and saw a communications error to a different Aeotec (battery type) sensor. The gate status was correct but the associated program did not run. I tried a couple of commands of on/off light commands through the console and nothing. Then a minute or so later I got the door annunciations and all the door on/offs and all was good. Thanks for the concern. I will be back with you when I can capture an entire event.
rccoleman Posted February 5, 2019 Posted February 5, 2019 This sounds a lot like the issue I reported back in 5.0.13, but with a simpler setup: I added a few new Z-Wave devices tonight and watched the ISY freeze and then rapidly process all of the backed events several times.
Michel Kohanim Posted February 5, 2019 Posted February 5, 2019 @KSchex, Thank you. Is it correct to say that the issue is communications related? If so, perhaps adding a range extender is a good idea followed by a heal (especially since the issue seems to revolve around battery operated devices). @rccoleman, unlike INSTEON, Z-Wave commands are short but numerous. So, there will be cases when the queue is large enough so that ISY will have to throttle everything. It's 100% normal as long as the commands in the queue are eventually processed. With kind regards, Michel
Rocketron Posted October 11, 2020 Posted October 11, 2020 (edited) Back to the original topic of this discussion. Does anyone know if the Mimo2+ works with 5.3.0? I'm trying to set one up to use with twin garage doors. Attempts at adding it to the ISY have produced only 2 nodes 1.Multilevel sensor and 1. binary switch. Seems the inputs and the other switch are missing. Edited October 11, 2020 by Rocketron
asbril Posted October 11, 2020 Posted October 11, 2020 51 minutes ago, Rocketron said: Back to the original topic of this discussion. Does anyone know if the Mimo2+ works with 5.3.0? I'm trying to set one up to use with twin garage doors. Attempts at adding it to the ISY have produced only 2 nodes 1.Multilevel sensor and 1. binary switch. Seems the inputs and the other switch are missing. I have 2 Mimo-lite for my automatic curtains and they work fine with 5.3 1
KSchex Posted July 17, 2021 Posted July 17, 2021 On 10/11/2020 at 6:41 PM, asbril said: I have 2 Mimo-lite for my automatic curtains and they work fine with 5.3 I know this is an old question/problem and probably been asked many times: Has the ISY been fixed so that it works with the Fortrezz MIMO2+????
Recommended Posts