apostolakisl

No, I tested this and posted it a couple posts ago. I just did simple REST commands ISY to ISY and added %20 followed by random letters to an otherwise functioning REST command. ISY returned error every time. ISY to ISY using the weather module variable substitution does not.

Except F and % sign apparently are part of ${mod.weather.temp.current} and ${mod.weather.humidity} YET, they still work direct ISY to ISY REST to a var. The exact same thing through the portal does not work. So I don't know what code is in there that tells the receiving ISY to ignore the string and just use the integer. And why this is lost with the portal? Whatever code it is, it is not %20. %20 seemed like a good candidate since in the email that seems to be the only thing separating the integer from the F or % sign.

A percent sign does show up in the email for humidity. None-the-less, it works. I tried test REST commands to my isy putting a %20 after a number (url for "space") thinking maybe isy truncates at a space, but it does not, it gives an error. For example, http://192.168.1.9/rest/vars/set/2/26/8%20 So there must be some other character there that tells it to truncate . . . cause it works when you use variable subsitution for temp and humidity. I would expect that the portal is not "understanding" the REST command, but rather just truncating all credentialing since it has already established a session with the target isy. There really would be no need to understand or interpret the command at the portal level.

Unless humidity puts a % sign, then it is not that. Humidity also fails via the portal. I would not expect the portal to pay any attention to the content of the message but rather simply act as a forwarder. And humidity works fine direct from isy to itself or isy to another.

I don't know how that is possible. There are no options that I am aware of to change that and mine is sending a number right now. It updates every time the number changes. I have a state variable for both humidity and temp that just updated with a 94 for temp and 43 for humidity at 8:31:37 (about 15 minutes ago). I have been running this network resource now through quite a few firmware versions, probably starting in the 4's through the present 5.0.13c. The only difference is that now I'm on the portal so I'm having to first have to loop it back via a LAN network resource to the originating ISY, then once I have it as a standard variable I can send it to the other ISY without exceeding the allowable number of characters.

No, it just sends a number. It works fine when not using the super long security key in the pathway that portal requires. I have been using it for more than a year when just going https direct using my self-signed cert. Now I got around the problem by network resourcing from my isy back to my isy and storing it as a regular variable which I can then send using portal since a regular variable has a much shorter name.

10 seconds. I count 115 characters in just the "path" section when counting all the characters needed to put in ${mod.weather.temp.current} variable. So maybe the 128 includes some other characters that aren't actually listed in "path"? It works just fine when I put in a plain number or a much shorter variable name. I tried ${var.1.1} which worked just fine. So I don't think time out is involved here. EDIT: I did a workaround. I have a network resource that writes the weather module temp to a local variable (just using my lan ip, not the super long portal path), then I use that variable to send to the other ISY. Unless someone knows of a better way to convert the weather module temp/humidity to regular variables I'm having to use a network resource to loop the value back into the isy.

The new firmware is not the reason the programs aren't working. The reason is, as you seem to be suspecting, that this major firmware update reset the "disabled" status. Normally, a firmware update does not reset that status, but the huge changes between 4 and 5 did. You just need to figure out which programs need to be disabled again. Typically, when you write programs like this, you organize them into folders so it is easy to see which ones work together, or at least have used a naming convention that makes the association obvious. If neither of these situations were true for you, you can use the "find" function and search for any program that references these programs. If everything worked before, you should not need to write any new programs or change current programs, aside from disabling the correct ones. Also, you may be able to go back to the old firmware and restore the backup I'm hoping you made prior to the upgrade. Then you can go through and make a note of what programs were disabled. Then you can update again knowing what to disable. I am suggesting this based on my belief that the disabled/enabled status is preserved in a backup, though I'm not 100% on that.

Both of those programs have "then" clauses which change the status of a device which is in the "if" clause. So the program will re-trigger itself and trigger the other program, possibly back and forth. If you want to check the status of a device in the "if" and based on that status change that status in the "then", then you must disable the program and have an additional program which does a "run if" on that program. The key here is to understand triggers. STATUS is a trigger upon ANY change in the device. CONTROL is a trigger only upon execution of THAT SPECIFIC command (ie switched on).

the red left edge means the last time the program did something, it was the "else" clause. disabling a program means it won't spontaneously run. In other words, the "if" clause will only check its own conditions when something else tells it to "run if". Typically another program or less likely from an outside REST command or by someone manually telling it to "run if/then/else".

See, you did figure it out. ?

Yes, putting the number "1" works (in place of the variable).

It works from a browser. I did not include the authentication in the url, I entered it into when requested afterwards.

Sorry, not sure exactly what you mean by the above. This is what the ISY network resource lists in the "actual" box. Again, this all works using my port forwarding directly to ISY. GET /isy/randomlettersandnumberscutandpastedfromportal/rest/vars/set/2/1/${mod.weather.temp.current} HTTP/1.1 Host: my.isy.io:443 User-Agent: Mozilla/4.0 Connection: Close Content-Type: application/x-www-form-urlencoded Authorization: Basic thenumbers/lettersgeneratedbyencoderusingmyportalusername/password Note:I do use a special character in my password, if that matters. Below is what actually works using port forwarding GET /rest/vars/set/2/1/${mod.weather.temp.current} HTTP/1.1 Host: myurl.no-ip.biz:443 User-Agent: Mozilla/4.0 Connection: Close Content-Type: application/x-www-form-urlencoded Authorization: Basic thenumbers/lettersgeneratedbyencodeusingmyregularuser/password

That was a typo (in the forum only). It is set to my.isy.io

I left my port as 443, which is what I was already using for https

Not working. I started with my working network resource and copied it. I was already using https, so no change. Changed host to: my.iso.io Added to the path all the info preceding the /rest . . .: /isy/lotsofrandomlettersandnumbers/rest/vars/set/2/1/${mod.weather.temp.current} Changed authorization to: logon username for portal (my email) logon password for portal And it gives me an error, tcp client read response fail

So on an ISY network resource from one ISY to another that currently works, I copy and paste the "URL to ISY" into the "Host" section, and leave all else the same? Including the "authorization"? Is this in the wiki? I didn't see it, but that doesn't mean it isn't there.

I'd like to send a REST command to the ISY through the portal. I have two ISY's at different locations and they send some info back and forth. Currently using my self-signed certificate to do this. But now that I have portal, I would like to close the port forwarding and go through the portal. The only way I see to do this is via IFTTT (though I'm not even positive on that since I haven't actually tried it), but that just adds a whole other step and confusion. I can turn the GeoFence nodes on/off via a URL that the portal generates. I would very much like URL's that can control other nodes/variables/programs/etc.

If you are doing this from a webbrowser, you only need to put credentials in once. After that, the session does not require you repeat the credentials for further queries. If you are doing this from outside your LAN, using http is wide open. Your user/credentials will be wide open to anyone who wants to intercept your traffic. This is easy pickin if you are on a public wifi. You need to setup https on your ISY.

The wiki doesn't point out that for every change you make to your echo configuration on the portal, you have to "discover devices" from the echo. For someone like me who has already configured the Google home and used the update button on the portal, this is not at all intuitive. The "live update" button would seem to be declaring itself as updating echo as you make changes, when in fact it is not. The wiki only says this about that button: Proactive State Update This will require the live update to be active. When you go to your Amazon Echo device list, make sure to enable the Live Update -- NOTE: This may not be working properly at this time I'm not even sure what the above means or if it is currently working or not. And if it needs to be on, why do we even have the option of turning it off? IN SUMMARY: 1) Wiki needs to document language for using inputs on AV 2) Wiki needs to explain what the live update button is for in more clear terms. I don't know why echo needs to receive status updates from my devices. Does that mean if I manually turn a light on, echo knows it? 3) Wiki needs to point out that for any and all changes to your echo configuration in the portal, you need to "discover devices", even if you haven't added any devices.

OK, I see where to hover now. Still, should put the language in the wiki. This stinkin language is quite specific and so hard to remember. Seriously, it is like the SNL skit where the old people keep yelling crap at their alexa.

Ive tried hovering over every different thing there is and I don't get any dialogue boxes. Using Chrome.

Yeaahhhh! It is the word "change" I needed. Need to add that to the wiki.