MWareman

There are two portal services compatible with the ISY. ‘ISY Portal’ is provided by Universal Devices (maker of the ISY) and ‘Mobilinc Connect’ - a portal service by the makers of the Mobilinc app. They both offer similar features (connecting to and from cloud services, remote admin console use etc). Check both out, compare the pricing etc... Both of the Portal options integrate with Google Assistant. The ISY Portal subscription also gives you a license to use the Network module on ISY. The Mobilinc Connect Portal does not. The Mobilinc Connect service only works natively with the Mobilinc app - while the ISY Portal implements its API to look exactly like a native ISY - meaning a range of applications can be used, like Agave or MobiLinc (there are lesser known others as well - but these two are the main ones). Choice of app should influence a little. If you have (or might switch to) Android - Agave may be the best choice (Mobilinc on Android does not support any of the plugins... while Agave is mature and well supported). If you are IOS only - Agave may still be the better choice if you like the UI (but is still very new to the platform) - but Mobilinc is more mature and very capable on IOS due to its plugin support. Additionally, as far as app choice... Agave cannot connect to the Mobilinc Connect Portal (the company want you to use their app to connect to their portal) but the Mobilinc app can connect to either portal.

I use several Google Home devices to issue voice commands via ISY Portal to my ISY just fine. The ISY Portal is not the only way to link Google Assistant to ISY but it’s certainly the easiest.

Nice catch... I have one Google Home where that was happening (working fine on the other 5 Google Homes I have) and I hadn’t put any thought to it yet...

I have the Basement Watchdog redundant sump system. Two pumps (different heights - 110v primary and 12v secondary), 4 floats (interleaved - so a failed float normally doesn’t completely take a pump out of contention) and dual power supply (110v and a deep cycle lead acid). The charge controller has a dry contact output that I have wired to my Elk (as a non-alarm zone) - and it drives my ISY. I had a float stick on a couple of months ago - caused the 110v pump to stay on and burn out during a storm. The battery pump handled the load and the system alerted me once the battery pump came on (about 10 mins after the 110v pump finally failed). I was able to replace the float and pump the next day without getting any water in the basement. Without the alert - I likely would not have known about the float failure for quite a while - putting my finished basement at risk. A great system. I recently added a current sensing relay to the 110v pump power supply - and have the dry contact of that going to another Elk non-alarm zone. I use that (with some ISY programs) to track runtime of the pump and correlate it with the Weatherflow rain sensor. That’s another way I intend to detect possible failures.

Your two ISY Portal user accounts both use the same email address. I’m pretty sure when you login you are only going to be using one ISY. The ISY Portal users must be separate email addresses - otherwise when you link your Portal to your Amazon account you won’t be sure which ISY Portal account you are connecting to?

In my Tasker tasks, I put a label before the http step - and test after the step for a successful connection. If not, I jump back to the label after a 1 second delay (to prevent a tight loop). I usually include a counter as well - so it does not loop forever - and can at least pop up an error if the connection is still bad after several attempts.

While it certainly would be nice is the Portal and ISY behaved the same - but it is correct what the Portal is doing and not correct what the ISY is doing. What you are trying to do should always have failed. The Portal is not 'processing the rest command' - nor is it 'not truncating'. Processing the full string is likely done by the Load Balancer (or other Amazon infrastructure) and is entirely correct. Truncating at the space is, per all standards, the incorrect thing (even though it's what allows your use case to succeed). It's a lack of processing code in the resource constrained ISY... I've said before.. adding the UOM to substitutions is the documented action. I've previously asked for a .RAW option on substitutions to direct the substitution to be made without the UOM added - but so far it's only applicable to the .ST value of nodes. If this concept were expanded to all substitutions that would solve this issue in a more sustainable way. If you have two ISYs - of course you could (as you document) send the values from one ISY to the other - relying on the truncation 'bug' to convert to an integer. Then you could send it back - or to Portal - now as an integer variable. I would caution that because you would be taking advantage of a likely unintentional 'feature' that it may stop working (or start functioning consistently) at some future version...

I think you may be misreading me. By adding %20 - you are causing it to fail because the ISY sees the characters %20 (NOT a space). It's a string. So, it fails. By adding an actual space followed by any character (like a F or %) - the ISY is truncating at the space. This leaves the integer and the write to the variable succeeds. Trying with a browser will behave as if you manually tried %20 - since browsers will implicitly change spaces to %20's.. Your experience is exactly as I would expect if the issue is as I speculate. Only UDI can confirm (or refute!) for sure..

You are thinking this the wrong way around. The portal uses a very mature web server process - and it’s likely got code to handle unencoded spaces and pass them down to the portal code (causing it to see a string and an error when it tries to stuff the string into an integer variable). The ISY has an extremely lightweight web server process, and in all likelihood is simply truncating rather than take up space with the code to properly parse. This causes the remains to be an integer, and that fits the integer variable. The correct response is an error. You should not be able to send a string with a F or % to an integer variable. Ideally, the ISY should provide a substitution variable that suppresses the UOM - resulting in an integer that works in both ISY and Portal. This is already true for the .ST value (using .raw) - but does not currently work for weather module variables. The problem here is that the ISY accepts the request (it shouldn’t) - not that the Portal should (its behaving correctly and rejecting the non-integer attempt to set an Integer variable). The correct fix is the ability to .RAW the weather module variable substitutions. Until the ISY can support this, it must be done by an external script.

%20 is a properly encoded space though in your test - it will get interpreted as a literal string by the Portal and the ISY - and when you try to stuff a string into an integer it will fail. Basically, that’s what I believe is going on here.... Your test is basically causing the REST call to your ISY to fail in the same way the REST call to the portal is failing. When the space is inserted by the substitution, it will not be encoded at all... I think the Portal handles that - and then fails (because the value is not simply an integer) while the ISY is truncating at the space leaving only the integer causing the request to succeed.

I’ll take a look at humidity tonight. I’d expect it to include the % - since UOM is almost always included in substitutions. The easies way to test is an email substitution sent to yourself. As far as Portal - no, it’s doing more than simply forwarding. If it were simply forwarding then the username and password you use would be that of the ISY.... Normally, the web server software http decodes incoming requests before passing them to the software for processing. Portal runs a full HTTP server process (something like Apache or Lighttpd, I don’t know for sure...) - and likely http decodes requests fully before passing them to the code that UDI has running there. On ISY, it’s an extremely light HTTP server process - and I’d guess that it’s not fully decoding the incoming requests - and instead they are getting truncated at (in this case) the space - allowing the requests to succeed to your ISY but fail via the Portal.

The reason upnp is normally disabled - malware that manages to execute on your machine (or even JavaScript delivered via a web page) would be able to open up port forwards - allowing the malware to host phishing pages for instance. Not at all a good idea. This is because there is no authentication in upnp.

Well - I was testing with email substitutions. To be sure, I tested with network substitutions and got the same result.... Using this network resource: The response, in the Apache log on the receiving web server, was this: 192.168.1.20 - - [19/Aug/2018:21:47:01 -0500] "GET ?test=75 F" 400 0 "-" "-" The "<space>F" is most definitely there... (5.0.13C in my case - but this was the case as long as I have been doing substitutions) My only guess.... Could the ISY be truncating the incoming request at the un-escaped space - causing the request to succeed... and the Portal handling the request properly (failing it..)? Edit: @Michel - Seems we need a .RAW for all modules (including the Weather one) as a method to suppress the UOM being added to the output of the substitution...

Not on my ISY... It sends the F or C as well....

The issue is that ${mod.weather.temp.current} gets converted to something like “86 F”. Two issues. First, you can only set variables to a numeric value. The ‘ F’ (or ‘ C’) will break this. Second, the space needs to be encoded. Encoding on ISY happens at time of saving, not at time of sending. Some values allow the use of adding .raw (as in ${mod.weather.temp.current.raw} - but it appears this does not work for values from the weather module. In short - you will need to use a script running somewhere else to do the conversion.

Take a look at posts 1 and 2 in this thread: https://forum.universal-devices.com/topic/5410-triggers-and-conditions-and-ifs-oh-my/ It’s linked from the online manual: https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:How-To_Guide#Programs

The same issue exists if you setup an Elk alarm to be voice disarmed - especially when using a program.... and with Google Home... Personally, I forgo voice control of locks and my Elk. Easy enough.

Woot! About time. This should have been the situation from when they first started prompting for devices to be assigned to room.... I can now add a *lot* more spokens!

Right-click the icon, I forget which tab, but find ‘Compatibility mode’ and change it to ‘Windows XP’. The issue is your screen is a HDPI screen, and Java does not play well with newer APIs that HDPI exposes. This seems to work around the issue for most people.

In my case, if I arm the Elk and one of my two zwave locks is unlocked - I send a ‘Lock’ command (rather than prevent to Elk from arming, or issuing a disarm). If the lock gets stuck - I send a high priority Pushover message to let me know. Works well enough for me - though I’d love to add the lock strike switch at some point...

All true, but question was asking about preventing the Elk from being able to arm (which requires a native Elk zone) vs having the ISY see an arm event and reverse it if the lock is unlocked. Same effect for sure (security wise) but I’d be concerned someone might arm the system and walk away, thinking they had armed it only to find out later their arm request was reversed because the lock was open. Notifications go some way to address this, but I’ll suggest that’s less than ideal. Personally, I’d rather have the ‘Not Ready to Arm’ indication on the panel with the zone in violation being the deadbolt. I believe that can only be done with a switch in the deadbolt strike plate (like one of these... http://www.sdcsecurity.com/Latch-and-Deadbolt-Monitoring-Strikes.htm)

I don’t think Mobilinc yet understands how ISY sends values with decimal components.... This is new to v5 - and Wes I believe said he was going to wait until v5 got more stable before fixing these things...

AFAIK - even if you connect the Elk zwave module to an Elk - you still cannot use zwave sensors as alarm zones. This is because zwave is not monitored by the Elk, and it can be rendered useless by a The best solution I can think of. I believe there is a switch you can place in the deadbolt strike - you could wire such a switch to a native Elk zone to have the deadbolt drive an Elk entry/exit zone.

They really should NOT change the specs like that without giving it a new product number....

I wrote most of that wiki article. Unfortunately, iMessage is a closed protocol. It’s not possible to send to it from non-Apple systems. Just like Hangouts on Android and Skype on Windows systems. The wiki page is intended to gather known alternatives so you can pick the solution that works for your application.