DCardellini01

Wow. Great idea! My only concern is what I understand to be the open door when a REPEAT (or WAIT) is invoked, That open door to allow other programs to run (interrupt is now available), and the fact that if original top conditional changes, the remaining code under your REPEAT may not execute. Do I have this right???

Yeah, Larry. In my world, these options here do not exist in ANY program: You are making a more complex program almost impossible to understand a year later, likely making troubleshooting in development far more painful, and in general, adding another confusing layer on top of confusion. Rarely in the controls world is the quickest, easiest program change, the proper change. Those that do not understand that will spend most of their time in frustration with troubleshooting, and use trial and error to fix problems. (which inevitably results in the dreaded "spaghetti code.")

Long time control system programmer, and developer of embedded controls using real-time operating systems. I have always tried to fit most control programs into a State Machine model, and rigorously use the Mealy State Model in my many years. Therefore, I only "do something" on state transitions (never on state). And I always start with a State Diagram. The ISY programming construct is pretty simple for simple things, but it is easy to get into trouble for more complex programs, and becomes impossible to read a year later when you have many "programs" interacting with each other. There are quite a few idiosyncrasies in the programming model, and there does not appear to be any document that warns you of these things situations and how to avoid problems. As such, I only use IF and THEN (not else). I NEVER use WAIT or REPEAT in the state machine. I have a timer service folder that services each timer with a decrementing WAIT (by the second, minute or hour). The instant that I set a Timer in the State Machine, that service program decrements the timer to zero, and there is usually another state transition in my machine that checks for TIMER_1 = 0 in a condition. ****************************** In any event, I struggle to see that the event-based paradigm of the ISY programming is "state-like." All control programing is about "controlling the internal state," whether linear, procedural, object-oriented, or in this unusual paradigm for event-driven. The ISY event-driven model, is, as you point out, a change-in-state model. Internally, the ISY is creating an interrupt for each and every change of status of every device/statevariable in the system, and allowing YOU to create an interrupt service routine for that individual generated interrupt (that is what a singular program is...and interrupt service routine). That paradigm is fine for a smaller system. But when you have many hundredor thousands of devices in larger systems, it becomes very inefficient and very confusing. Better to snapshot the entry state of all devices, run your logic, modifying variables and device state in as output. Traditionally, for control systems, interrupts can cause lots of unforeseen problems, and you use them sparingly for only those things that need incredibly fast response time. And you severely limit the the length of code behind the interrupt service routine. I think the ISY, and now the Polisy, are fantastic, incredibly robust products. The event-driven paradigm works well for the intended target audience. ********************* Back to the State Machine Model for programming ISY: The beauty of sticking to one State-Machine model (I prefer Mealy), is you can implement your State Machine model on ANY programming environment, and spend 90% of your time on a scrap of paper working through your State Diagram. Converting that to code can be done by someone else. And a year later, you simply look at your diagram to dig into any required changes.

OK. I made the leap and bought a Polisy. I was a bit worried that it would be a time-consuming geek project, playing with an ssh session or two, getting ISY loaded up, then getting the HUE Node server integrated. I received the Polisy, booted up, got my admin console app, and connected to new polisy. And there it was.... ISY already installed, and looked no different than my existing ISY. Plugged in my serial PLM with the db9 cable I just ordered, and Insteon devices now connected. Plugged in USB Zwave dongle, and got my Z-Wave devices going. Then pressed the link in ISY for the Node server, a web page pops up, entered my admin user and password, went to the store and loaded the free Hue Node server. Magically, all my Hue devices now show up in ISY. And the functionality within ISY is identical to Z-Wave (and very nearly identical to Insteon). It is seam-less and it is brilliant. Congrats to Michel! Why did I wait so long? My only complaint is the form factor of the Polisy. I have made a small shelving unit to hold all my "small electronics" to keep it organized: Hue, ISY, Roku Ultra, EtherSwitch, Intel NUC server, Harmony Hub, ViewHD HDMI switch, HDMI splitter, etc.. Without some attempt at organization, that is a messy proposition. The size of the Polisy just won't fit on that shelving unit., and the ZWave dongle sticking out even worse. (yes, a right angle adapter on way... just not sure about the antenna pattern in that orientation). I thought this whole home automation thing was dead with the expired INSTEON business. I now see the future if Insteon is permanently gone. As of yesterday, my PLM is going bad (reset/reload several times) and spotty connection to devices. But the fact that most my Insteon devices still work with no connection to the ISY makes me remember what a brilliant system that was (is?). Sorry that Michel did not get the biz, but hopeful good, cooperative relations there. But NOT paying $500 for used PLM. Have an eBay Re-Cap kit on its way.

Thx for update, @roberthleeii. Made my purchase this morning.

@kzboray and @lilyoyo1: Thanks so much for your help here. I kinda knew I would get a bit of a beating for my more aggressive request for help. Yep, I deserved that. Perhaps the most important point was that I did not aim for success with new top-level thread post. I tend to not want to do that, and see value in enriching an existing thread on related subject that had run its course (not hijack and change on-going discussion). Apologies for any ruffled feathers. I often look for solutions on forums first, and have done many times in past here over past 16 years. When I absolutely hit a brick wall, Michael has always come through with fantastic support. Again, THX! I'll be ordering the Polisy shortly. Just needed to build my confidence a bit.

Kind of surprised at lack of support on this thread. Perhaps the information I seek is readily available and I just have not done my homework before asking here. Or maybe this is just a fringe application (Philips Hue device control through ISY) that just doesn't get much interest on the forums. Not just my questions, but roberthleeii and dthomson questions too. Was ready to pull the trigger on the Polisy, but tepid support here makes me hestitate.

Thx roberthleeii. In general, I see no reason to make scenes/groups in the Hue Hub. Prefer to keep the intelligence in one location, and that is the ISY (and prob Polisy). Are you keeping a separate box for ISY and the Polisy Box, or are you hosting the ISY functionality in the Polisy? It does sound like I want the Polisy. Hope others will weigh in. thx again.

StangManD: Thx for posting this. Long time ISY user (about 16 years), but never touched the Node server path both pre-Polisy and now. Not even familiar with the concept and how it integrates in. I have a new setup that really needs lots of bulbs of different types: standard, BR30, PAR30, PAR20, chandelier, etc. And Philips really appears to be the only reliable game in town....so I bought a ton of bulbs and have them running under the Hue right now. And of course lots of Insteon stuff, and especially wall keypads and mini-remotes (really important and mind-boggling that neither Z-Wave nor Zigbee has filled this path). Now it is time to integrate it under my ISY994IR-PRO. Found a great post on here for how to quickly communicate to the Hue Bridge via REST commands in ISY Programs. And I guess the proper integration is to make two programs for every scene that includes a Hue device, and have those programs called when the Scene is turned on and off. It just seems kind of messy when 50% of my stuff is under the Hue. So to my Question! What improvement can I expect if I buy a Polisy and use the Hue Node server? Can I simply add Hue node devices directly into Scenes as if it were an Insteon Device? Is there two way communication like Insteon for use in programs (like "if HueDevice1 is switched on, then do X") Is the ISY functionality build into the Polisy yet, or do I need two boxes? Thx in advance for a rough comparison for the non-Node server approach to Hue with REST commands, and the Polisy- Hue Node server in practical application. Dave

Since I upgraded to latest 5x version (in December) I stopped receiving my email notifications. First problem was that the "from" field in the smtp dialog had gotten blanked out. Fixed that, and NOW able to do a test send. But my programs that send the notifications would not send emails. I discovered that if "variables" are included in the SUBJECT field, the email will not get sent. The emails WILL get sent if I remove the variables from the SUBJECT FIELD, and place them in the BODY field instead. This has worked a long time with variables in the SUBJECT field, and allows me to glance without actually opening the message in my email clients. Thx in advance for anyone that can verify that this is indeed a bug, and any workarounds.

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."

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.

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!!!

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!

Just as a follow up, I did get the MIMO2+ unit some time back, and it works great. (HVAC air handler blower speed control) Out of the box, the relays are set to momentary. Using the "Binary Switch" device, set the ZWave parameters 1 and 2 both to "0" instead of the default "5" for latched operation. Start by selecting the Parameter number you want to change, and hit "Query" to grab the current value. Then change it, hit "Set," wait, then "Query" again to make sure it took. Played a bit with the two analog inputs. I set up both inputs to update as fast as possible (Parameter 3 (for Sig1) and Parameter 9 (for Sig2) each set to -127. This gives updates that vary between 12 and 20 seconds. They have a downloadable application helper that guides you to the proper parameter values to use. The input is not clearly defined in the literature. You will measure 2.725 volts between sig and common with nothing connected.You better have a low/zero impedance voltage source capable of both sourcing and sinking current (as signals below 2.725 volts will want your source to sink current (yeach). I characterized both inputs and was disappointed not so much by the nonlinearity, but by the garbage at the bottom end: Essentially, below 0.6 volts, it is very funky. In general, it doesn't seem to be filtered internally, as successive readings (12-20 seconds) change 10's of counts (with a very stable signal source). Given the instability of the signal (no internal filtering), the non-linearity (difficult to linearize in ISY), and the garbage relationship below 0.6 volts input (unusable), I give it a "fail" for my application (cheap SCT current transformer conditioned with AD8436 RMS converter).