MWareman

I can now see each room in my house getting an Alexa to sit right next to my Google Homes. And double the admin overhead as well... I know..... I have my Elk hooked up to several speakers for announcements currently. I should setup a single house-wide ‘announce only’ Alexa.....

Have you assigned any spokens to devices?

I was just mulling where this was at? Any news to share...

IFTTT 'alternatives' I can find quickly are: Stringify Automate.io Microsoft Flow Zapier Pipes (https://www.pipes.digital/) Workflow (IOS) Tasker (Android) Granted - the last two are not truly SaaS - but commonly are integrates using Webhook functionality. I know personally I use 4 of these (IFTTT, Stringify, Flow and Tasker). Currently - I route non-IFTTT requests to my ISY thru a personal Apache host (since I have a publicly trusted SSL cert) so each can use it's own key - and the Apache config adds the Authorization header for the ISY if the key matches one of the three I have assigned. Certainly - allowing a certain number of keys to be valid (10?) would be of benefit to me - but I'm not sure how many others would benefit (or even realize that there is a benefit) to seperate keys for each separate service or device being connected. Michael.

Awesome! Thank you. If we are making requests, is it on the roadmap to support more than one Key? (With a key name tag)... The use case is more than one system. If I share a key with IFTTT and another cloud service - best practice is I share different keys. That way if one service gets compromised I must only revoke that one key... Thanks!

Or “IFTTT / Webhook URL”

Don’t know about Mac, but from Windows if I downloaded admin.jnlp directly from the ISY and ran it it would work without Internet access... http://192.168.1.2/admin.jnlp (adjust for your ISYs IP) Java apps generally must be able to access the URL you download the .jnlp from when you launch it. So, downloaded from UDIs servers it won’t work if you don’t have internet connectivity.

If rehashing the weather module, why not make it free/cheap for the module itself, then separate the data feed. User pays a monthly cost for a premium data source (like Aeries), or can use their own data feeds (a personal api key for WUnderground, a local meteobridge sourcing data from any number of station hardware, or even a local Weatherflow UDP data feed....

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.