Teken

http://forum.universal-devices.com/topic/10516-random-all-on-event/

Hello John, In case this was not made obvious in any of the forum posts or literature you have read. Native scenes / linked devices operate faster than a program initiated by a controller like a 994 Series Controller. Scenes / links are not dependent upon a controller being active and operational. Should a controller fail or a program not execute a native scene / linked device will always operate in a manual fashion. Best practices are to link all devices in the home to provide native control and fail over. Use programs only when more logic features, capability, and timing / scheduling are required. Lastly, as was noted in the other thread with respect to the 2406H coupler. This device is passive in nature and does not repeat or strengthen the Insteon signal. It also does not provide any RF to power line bridging either. Any dual band device will repeat, regenerate the Insteon signal in the home and also bridge RF to power line communications when and if required.

My understanding is this was done to ensure a wet condition was seen and locked in place. This would then necessitate the user to physically check the sensor and local area for a wet condition. I see value in both methods for those specific use cases so this really doesn't bother me. It comes down to first knowing the expected behavior and next programming for such. As the first generation leak sensors would simply flash and return to a dry state immediately upon wet detection. It also did not flash its LED in a cycle to indicate the wet condition either. Later iterations of the leak sensor were much better and those are the ones you and I have were it would return to a dry state once the wet condition resolved itself which required no user intervention. The problem here is if a wet condition was restored to a dry state this incident may not be tracked by the user. So I can see value by Smartlabs in locking in the wet condition and forcing the user to physically inspect and manually reset the leak sensor from wet to dry. My goal in this thread was to document a out of band behavior which was the sensor would repeatedly send a wet condition in excess of 4 times. Pressing the reset button had no effect on the unit to change it back to a dry state. As we all know battery operated devices send multiple signals when activated and gather this is done to ensure the signal is received by the Insteon network. This was expected by me, but again what was not expected, is that it was broadcasting well past the three times. The unit also would not reset itself when manually pressed which confused and frustrated me to no end! After hard resetting this device several times and reviewing the level 3 error logs to confirm what I saw. I didn't want to take a chance this was defective unit and sent it back to Smarthome. The RMA unit I received back operates as expected and its possible the one I had on hand was simply defective or not programmed correctly from the factory.

Natively no but the new portal will allow multi login and reduced user rights. But it requires a $49.XX investment in the portal integration module which covers two years subscription. Perhaps in the future this multi login and reduced rights will finally be released to the public as its been a feature request for many years.

I think the above is an excellent alternative for sure but not sure if having another device in my home is something I am willing to take on. Perhaps I may think differently if the other solution fails or realize it won't accomplish the end goal. Maybe I am a little jaded but some of this seems to be on the surface a easy thing to do yet its apparently not! One would figure in 2015 things would be much easier to accomplish but the reality it takes more resources and effort to meet these goals. Much thanks to everyone who has taken their time to offer their insight and feed back. Its safe to say this information will help others who intend to accomplish the very same. Cheers!

For those who wanted to see the DEFCON video you may view it here via this link: I can't honestly say the information that was presented was anything earth shattering to me. The initial presentation did high light that the white paper spec were off when compared to real life. But, that in it self isn't something that would cause me too much concern with regard to security. It came across as another lazy, inept, ability from Smartlabs to communicate and document the real world technical specifications as they are. Nothing earth shattering here as we have all seen this for ten years where they don't offer any insight about new product API's or even engage their largest supporter which is UDI. This was seen on the latest Alert Module, Morning Lock, etc. Again piss poor communications is par for the course here . . . As the presentation went on I was disappointed in the fact nothing was shown to the audience besides commentary about data that was captured on the screen? I can't honestly say I was moved in the least from this presentation never mind parts of the presentation were near impossible to hear as EVIL Pete did not have a working microphone for about 3-5 minutes. Later when he did have a microphone it didn't really show me anything a lay person would expect. It seemed there were a whole bunch of nerds sitting in a room chatting about how some elements were not accurate, or simply done poorly. Again, lazy, inept, and zero communication and lack of accuracy of documentation has been known and continues to be seen even today?!? Nothing new here . . . What I was expecting to see is a real world demo of a MS sending a on / off signal event. In turn EVIL Petes little dongle would capture the data packet live on the screen. From there he would discuss what had happen and what next steps could be taken to spoof or duplicate said data packet. All I saw was some kind of half assz lock demo that didn't do anything because half the parts were not present to complete the demo?? There was no lamp or other Insteon gear as far as I could see being used for linking / pairing, or otherwise? Then there were segments of ramblings which for me made no real difference about Manchester encoding etc. That portion again made no difference to me at all because the lack of attention or detail has been known for ages. The only take aways from this presentation was that there is no real encryption in the protocol which was shown in the demo screen. Perhaps I was expecting a lot more from this video but I can't lie I wasn't at all impressed with the presentation and it didn't show anything to me at least from a lay persons perspective of something being hacked. EVIL Pete, My humble suggestion is that you create a new video showing in simple terms a Insteon RF broadcast is being intercepted. Next this data is captured on the terminal screen and explain in detail what that data is. Finally, use the RF dongle to actuate several dual band devices while the data stream is captured in the terminal window. This in my mind would show the audience what can and is being done. I guess maybe seeing other DEFCON presentations which had solid presentations made this one seem off and lack luster. I hope you are able to make up another video so the content and hack can be shown to all.

One method that has worked for me in the past is to clear the Java cache and select all three option box's. This will remove the Admin Console icon from the desktop so ensure its still listed in your downloads folder. It should be noted this procedure always worked prior to the 4.X.X firmware releases but is a hit or miss now.

I track what you're saying and your over all intent but from a IT perspective its first rule you don't break. Best practices state each and every device must have either a unique IP (static) address or be reserved via MAC reservation / filtering. This avoids duplicate IP conflicts and reduces networking conflicts. There are many older / newer network based appliances that have transitioned to using software instead of embedded burnt EPROM / BIOS chips which allow them to change the MAC address / device ID's. This sort of deployment is a complete cluster f^ck waiting to happen . . . As they allow critical identifiers to be over ridden or corrupted which can lead to endless IT Support calls and is near impossible to identify until someone does an audit to determine the root cause. You don't have to ask me how I know this either! On Topic: Ideally you should be segmenting your network on to another subnet. This would allow you to have similar naming conventions (IP's). The reality is if you have to swap things out on a consistent basis in your network you have bigger problems to address than a IP conflict. Ultimately, any secondary back up unit should simply be left in DHCP mode and when its connected. You would have reserved the MAC address so its going to be issued a known IP address. Once documented on the wall, chart, what ever there isn't a need to worry about future IP conflicts or where an appliance will go boom.

You didn't answer Mwareman's question about how old the 2413S PLM is? If its a pre 2.1 hardware release you're simply buying time and your future holds another round of missing links and going through the whole PLM restore again. If this unit is close to 2 years old or older and is not a hardware 2.1 which is listed on the back you should consider replacing the capacitors or purchase another 2413S PLM because its a ticking time bomb.

I'm sorry, but that makes no sense at all from a networking or from a practical use case. Assign the other 994 a different IP address problem solved. You're causing yourself more headaches for no apparent reason?!! Given the fact this other unit will be somewhere else why even bother having two units with the same IP address? Also, if you assign two different IP address you can have both connected and available on the same network. I would think that would make more sense and remove any sort of technical issues which you're causing yourself.

http://forum.universal-devices.com/topic/17271-hub-ii-isy-echo-integration/

I prefer Southwire cable to be honest. [emoji53] Ideals are peaceful - History is violent

First thing to note is both firmware and UI must match yours doesn't. Next clear your Java cache and download the correct admin console in the firmware page. Report back what happens from there. Ideals are peaceful - History is violent

The HUB II supports Insteon and the three brands I mentioned above. The HUB Pro is Apple Home Kit certified and enabled. It will allow you to *ideally* integrate with any home kit device in the market place. It does not support Echo though. Ideals are peaceful - History is violent

If you look under my profile there is a thread I created that details how another forum member was able to integrate the HUB II with the 994 Series Controller. Doing so allowed them to have native Apple Watch, Echo, Harmony support. All the while still having the power and flexibility of the ISY-994 Series Controller.

As I understand it, the over all goal is to develop this hosted service to allow more 3rd party hardware and cloud service integration. It will also allow multi user / multi login for those with more than one unit. It helps integrator's manage multiple sites via a web based interface.

My humble suggestion is to set up your Insteon network so it operates on a basic level. Once that is done you can move forward and become accustomed to how the 994 Series Controller uses If, Then, Else conditions in its state driven logic. Once you get a basic handle of conditional programming you have many directions you can move toward. Do you wish to integrate a TSTAT? If so what are you looking for simple Insteon integration if so buy it from Smartlabs. If you believe you need more control and features then you can purchase any of the Z-Wave products or a networked TSTAT like Venstar. Next, are you looking to interface with more 3rd party devices and services? If yes then the network module is in your future . . . If you want to have even more integration with other fad products like the Amazon Echo / IFTT then you can purchase the portal integration module with reoccurring fee.

Answers in line . . .

KMan, As always I thank you for your time, insight, and guidance. I will need to sit down and review the actual needs vs goals so it can be defined and expectations set. Once that is hammered out to go through the process of testing, validation, and full deployment. Right now I am setting the expectation factor to (low) so there is lots of wiggle room for me and others. I've resisted incorporating any sort of cloud based services into my HA system for obvious reasons. But at this juncture it seems the cloud is the only *easy* method to get what I need at the moment. I would love a more direct route but my current cUL standing limits me to using this sort of solution.

Kman, That's just awesome I knew it wasn't just a dream in my head! [emoji38] Now given the information provided in the link above. It appears I will still need to wait for intermediate certificate support if I want to accomplish some of this locally? The first step is to sign up to IFTT and see how all of this is actually glued together. [emoji53] So briefly am I correct to assume the IFTT service will essentially filter key words in a email header and based on what I have programmed the maker channel to do it will in turn activate a variable of my choosing? [emoji53][emoji4] I want to make sure I fully understand the basic premise and what all the caveats and limitations are. For those wondering and following this thread I will not be using this for time sensitive / mission critical events. This is more for a proof of concept for a couple of projects under development for my home and another site. Thanks Kman! Ideals are peaceful - History is violent

Hello K5map, Absolutely, and it has nothing to do with being on 4.3.26 at all just for your own edification. Keep in mind you don't need to use his program at all but use a simple one. The reason I and pretty much everyone uses his excellent program is that it has several checks and balances which are very well thought out and proven to work. Off the top of my head the main driver to use Belias Leak Sensor program is that it checks to see if the program is running if not notify the user. Next, indicate if a sensor has missed the 24 hour heart beat window and continue to monitor and declare a fault until such time as the heart beat is seen etc. Lastly, you can modify the existing program to indicate the open-close sensor has tripped instead of a leak. In my use case I have them wired to a 3rd party localized flood stop units around the home. This essentially allows me to integrate Insteon into my HA system and security alarm panel for a modest cost and *No brainer install / notification* Ha . . . Merry X-MAS!

Hello, The Open-Close sensor still only has the three nodes: Open, Closed, Heart Beat. Please keep in mind it does not offer any method to fine tune any values like was seen in the hidden door sensor. Also, as stated above the current 4.4.1 Beta firmware does not support the ability via software to enable the two node option which is a requirement now since the mechanical jumper has been removed from the hardware device. Lastly, the heart beat function in the open-close sensor in most cases serves a better purpose when compared to the low battery warning in my mind. Don't get me wrong, it would be ideal and better to have both like is in the hidden door sensor. But since that isn't present the heart beat feature does in a general sense offer better insight. Because if you're in range of a dual band device the heart beat will be received and if not it wont. If you also don't receive a heart beat with in the 24 hour period using Belias excellent leak sensor program than its assumed its out of range of a dual band device or the battery is dead. So in essence the heart beat provides RF distance confirmation and battery state.

Hello Paul, Is there a possible way to send all of that in email header? As this will be done internally via a on site SMTP mail server. If some kind of API call can be done which does not require sending credentials that would be even better. Essentially I want to see if a trouble / fault e-mail that is issued by another appliance can be used to initiate something on the 994 Series Controller.

I am not sure if this was my imagination or indeed this is something I read here or else where. But is there a method to send an e-mail to the 994 Series Controller and have it trigger a variable that will in turn send out another e-mail? I know this sounds kind of convoluted and maybe it is. Essentially I would like to know if there is a simple method to send a API call to the controller and then have it react. The use of an e-mail was just a simple example for others to follow.

Yeah I received quite a few of those special offers some of which were really great. They had a BOGO for leak sensor I believe and also a discount price for the Amazon Echo with various Insteon hardware. At the bottom of each sales add was a 20% discount listing off what products were covered under the promo. There was an error I saw on one listing and was only seconds of hitting the submit button until their IT guru's caught the mistake! I could have made out like a freaking bandit as I had 4 of them in my cart!