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