Jump to content

Recommended Posts

Posted

Hmm, I have numerous Network Resources and am able to both export them as well as do do ISY backup. I am also on 3.1.16

 

Did you have just one resource or a number of them? Also, your gui is 3.1.16?

 

tim

Posted

OmegaQuest

 

The GUI level can be found by going to Help | About. There are two lines, Firmware which is the ISY firmware level and UI which is the Admin Console code level. They should both indicate 3.1.16. If the UI line does not show 3.1.16 or the UI line does not appear at all clear the Java cache and use the URL for invoking the 3.1.16 Admin Console.

 

Lee

Posted
Hello Bruce,

 

That's not good. So, in short, you are sending ONLY one command which repeats the IR signal 6 times on its own, correct?

 

With kind regards,

Michel

 

Hi Michel,

 

That is correct. I am sending one command from the ISY-99i to the IPTOIR to have it repeat the the IR signal 6 times.

 

Regards,

Bruce

Posted
Hmm, I have numerous Network Resources and am able to both export them as well as do do ISY backup. I am also on 3.1.16

 

Did you have just one resource or a number of them? Also, your gui is 3.1.16?

 

tim

I only had the one.

 

 

OmegaQuest

 

The GUI level can be found by going to Help | About. There are two lines, Firmware which is the ISY firmware level and UI which is the Admin Console code level. They should both indicate 3.1.16. If the UI line does not show 3.1.16 or the UI line does not appear at all clear the Java cache and use the URL for invoking the 3.1.16 Admin Console.

 

Lee

Both the UI and Firmware are 3.1.16

Posted

I am not sure if this is related ot the issues described in the thread, but I have been having extraordinarily strange behaviour with Programs And/Or Networking Resources. It is hard to pinpoint exactly what is happening, but the best I can describe it is that my program commands to send network commands get either lost, sent in the wrong order, or the timing is wacked.

 

Specially the one instance I can recreate is a pown on sequence for my Home Theater. I send IR and Network commands to get things going, and have pauses in to assure that devices power on before getting any further commands. Some commands that are supposed to be sent before a wait delay, get sent after the paude, and frequently in place of the command that was positioned after the wait.

 

Here's an example:

 

Set Scene 'Basement LED On'
Resource 'Basement LED Yellow'
Resource 'Home Theater Receiver Power On'
Set Scene 'IR TV Power On'
Wait 1 Second
Resource 'Directv Home Theater On'
wait 6 seconds
Resource 'Home Theater Receiver Volume -26DB'
Resource 'Home Theater Receiver HDMI 2'
Wait 30 Seconds
Set Scene 'AV rack LED Off'
Wait 1 Second
Set Scene 'Home Theater Nook LED Off'
Resource 'All LED Ambience'

 

Okay, so what happens is that the switch to HDMI 2 on the receiver happens AFTER the 30 second delay. The final network command to adjust LED lighting to ambience levels never happens until I execute another program with a network resource and it triggers then.

 

It is almost like the caching/queuing of the network resource commands has a defect.

 

Please help!

 

Thanks

Posted

Hi Bruce,

 

Thank you. Does this crash the unit all the time and is reproducible?

 

With kind regards,

Michel

Hello Bruce,

 

That's not good. So, in short, you are sending ONLY one command which repeats the IR signal 6 times on its own, correct?

 

With kind regards,

Michel

 

Hi Michel,

 

That is correct. I am sending one command from the ISY-99i to the IPTOIR to have it repeat the the IR signal 6 times.

 

Regards,

Bruce

Posted

Hello morgan4x4,

 

As we have noted in the instructions, the way in which we handle network resources has changed and thus, now, they run in a separate thread. The only thing that the program does is to queue the activation requests.

 

So:

 

Okay, so what happens is that the switch to HDMI 2 on the receiver happens AFTER the 30 second delay. The final network command to adjust LED lighting to ambience levels never happens until I execute another program with a network resource and it triggers then.

 

This basically means only two things (though it's rather unlikely that the delay would actually be 30 seconds):

1. The previous network resource activation had a timeout of more than 30 seconds and it actually took 30 seconds to complete

2. The program itself turned to false and then back to true (while waiting) and everything restarted from scratch

3. ISY is busy doing things with much higher priorities (unlikely)

 

So, my recommendations are:

If you really have to use a wait command, ensure that the condition does NOT turn to false while waiting. You can do this by putting those that require a wait in a separate program. i.e.

Program 2, has NO conditions:
Resource 'Basement LED Yellow'
Resource 'Home Theater Receiver Power On'
Set Scene 'IR TV Power On'
Wait 1 Second
Resource 'Directv Home Theater On'
wait 6 seconds
Resource 'Home Theater Receiver Volume -26DB'
Resource 'Home Theater Receiver HDMI 2'
Wait 30 Seconds
Set Scene 'AV rack LED Off'
Wait 1 Second
Set Scene 'Home Theater Nook LED Off'
Resource 'All LED Ambience'

 

This will ensure that this program will always run to its completion. This said, the first thing we have to do is to make sure that your condition does NOT turn false. Also, if you long timeouts in Network resources, you need to make them shorter.

 

With kind regards,

Michel

Posted

By any chance can you guys add more options in the programing sections, such as the ability to do "multiple":

 

ELSE IF

 

I hate creating multiple programs when one program will work with a few ELSE IF statments.

 

Thanks

Posted

Thanks for the pointers. You should be aware that the final command in the sequence I showed will not execute at all until another network command is issued. This could be 30 seconds or 30 minutes. I still suspect a deeper issue here.

 

One other thought, if I reboot the ISY, then everything works fine, for a while. Eventually it returns to the situation I described.

 

I'll play around some more, but still think there may be something odd under the covers.

 

 

 

One final thing... I get these in the error log:

 

 

Sun 2012/01/08 04:36:43 PM System -170001 UDQ:Queue Full: LOG

 

Could this be related?

Posted

Hello OmegaQuest,

 

We do not have any plans to support nested Ifs.

 

Hello morgan4x4,

 

Can you do me a huge favor? Can you add a notification email right before the last net resource activation? If you get the email but the net resource is not activated, then you might be on to something. If not, then we have to figure out what breaks the last wait and what other programs you have that might be activating that resource.

 

Log full right prior to Start is completely normal. If you have other errors, please post them here.

 

With kind regards,

Michel

Posted
Hi Bruce,

 

Thank you. Does this crash the unit all the time and is reproducible?

 

With kind regards,

Michel

Hello Bruce,

 

That's not good. So, in short, you are sending ONLY one command which repeats the IR signal 6 times on its own, correct?

 

With kind regards,

Michel

 

Hi Michel,

 

That is correct. I am sending one command from the ISY-99i to the IPTOIR to have it repeat the the IR signal 6 times.

 

Regards,

Bruce

 

Hi Michel,

I have been able to reproduce the error/lockup several times. Sometimes it occurs on the first time the command is sent fro the isy-99 and on others it occurs the second or third time the command is sent. I have been waiting around 30 seconds between resending the commands when it takes more than one to get a lockup.

 

Regards,

Bruce

Posted

Hello OmegaQuest,

 

Figured out how to add a display name to email address. In 3.1.17 (to be out shortly), all you need to do is to use:

name1 name2:email_address in the From field. ISY will automatically parse and send name1 and name2 as display name. Please note that most SMTP servers require name1 name2 separated by a space.

 

Hi Bruce, thank you. Since I do not have an IPTOIR, my tests did not crash the unit. Would you be kind enough to unplug your IPTOIR unit from the network, run the test, and let me know if the unit still crashes. If not, then we will have to use a packet sniffer to see what IPTOIR is returning (in those cases) that ISY does not like.

 

With kind regards,

Michel

Posted

Hi Bruce, thank you. Since I do not have an IPTOIR, my tests did not crash the unit. Would you be kind enough to unplug your IPTOIR unit from the network, run the test, and let me know if the unit still crashes. If not, then we will have to use a packet sniffer to see what IPTOIR is returning (in those cases) that ISY does not like.

 

With kind regards,

Michel

 

I tried today with the iTach removed from the network. I get a different error message in the error log and no lockup.

 

Error message with iTach disconnected Mon 2012/01/09 12:42:12 PM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 16

 

I did notice that there is an error while recovering from the lockup and not sure if this is related.

It is "System -170001 UDQ:Queue Full: LOG" It occurs 3 times in a row during rebooting.

 

Let me know how you want to proceed. In the meantime, I am going to try locate a router that I can install dd-wrt so that I have a network device that we can monitor the packet data on. It was a lot easier in the days of network HUBs.

 

Regards,

Bruce

Posted

Hello thedishking,

 

Yes, please and please do let me know:

1. Whether or not you have ELK and/or ELK Module

2. Whether or not you are using network resources

3. Whether or not your programs continued to execute

4. Whether or not you have any information on how to reproduce

 

Hello k7zpj, thanks so very much. During reboot (right before Start) UDQFull:LOG is completely normal.

 

You really do not need ddwrt or anything else. All you need is Wireshark and capture the traffic between ISY and IPTOIR when the network resource is activated. I am so very sorry that you have to do this but it would help us tremendously.

 

With kind regards,

Michel

Posted
Hello thedishking,

 

Hello k7zpj, thanks so very much. During reboot (right before Start) UDQFull:LOG is completely normal.

 

You really do not need ddwrt or anything else. All you need is Wireshark and capture the traffic between ISY and IPTOIR when the network resource is activated. I am so very sorry that you have to do this but it would help us tremendously.

 

With kind regards,

Michel

 

I will try to get the network trace done tomorrow. It is going to depend on how busy it is at work.

 

My network at home is all switched so the computer that I have WireShark on can't see the traffic between the ISY-99i and the iTach. I had one of the network guys at work double check my filter to make sure I had it correctly configured. The switch that I have in use doesn't support port mirroring so that I is why I mentioned DD-WRT on another router as an option to be able to see the network traffic.

 

Any thoughts on how best to go about the trace?

 

Regards,

Bruce (K7ZPJ)

Posted

Hi Bruce,

 

Thank you and now I understand. Unfortunately I do not know of any other way.

 

Questions:

1. What's the timeout for this resource? Do you know approximately how long this command should take (when repeating the IR signal 6 times)?

2. Have you tried opening the Event Viewer on "Device communications events" level and see whether or not some IR signals are bounced back to ISY (that is if you have the IR version)

3. Also, is it possible to run this resource from another program and just copy/paste the output? If not, does the API define what should be returned?

 

With kind regards,

Michel

Posted

That is Great News about the Email Name showing in the From Field. Can this be added to the Text messageing section as well?

 

Thanks Michel

 

** On another note, I have noticed that since I updated to 3.1.16 that when I log into the Admin GUI, "sometimes" the status dosnet show on of my devices and if I make a change (like move a device to a scene), nothing happens (if I turn a device on and off, that works, but the status is still blank) until I disconnect and log back on. Then the changes I made (moving a device to a scene) will display.

 

However the devices status I have to disconnect and log back on "several" times for it to pick up the status.

 

Thanks

Posted

Hello OmegaQuest,

 

Text should work as well but have not tested it thoroughly.

 

Status issues are usually firewall related: your computer's firewall is blocking ISY from publishing events to the Admin Console. In the best case, all you would have to do is to put ISY in the trusted zone white list or exclude from checking. In the worst case, you have Avast or Kaspersky in which case you have to do a lot more things to get it to work.

 

In most cases, though, if you use HTTPS instead of HTTP, then the firewall lets it go through thinking security is done at the certificate level.

 

With kind regards,

Michel

Posted
Hi Bruce,

 

Thank you and now I understand. Unfortunately I do not know of any other way.

 

Questions:

1. What's the timeout for this resource? Do you know approximately how long this command should take (when repeating the IR signal 6 times)?

2. Have you tried opening the Event Viewer on "Device communications events" level and see whether or not some IR signals are bounced back to ISY (that is if you have the IR version)

3. Also, is it possible to run this resource from another program and just copy/paste the output? If not, does the API define what should be returned?

 

With kind regards,

Michel

 

 

Hi Michel,

1) I wasn't able to determine the exact time for the resource time out from the API spec. Based on the formulas in the iTach API Specification document, I calculated it would take 100ms to transmit one IR sequence. I don't know the the pause time is between transmissions so I don't know the total time it takes to send the IR sequence 6 times and return the success message.

 

Here is the link to the API http://www.globalcache.com/files/docs/API-iTach.pdf

 

2) The ISY and iTach are in different locations so I will have to relocate the iTach to try this.

 

3) I used the Global Cache iTest program to send the IR command to the iTach.

Command Sent: sendir,1:1,1,38000,6,1,343,172,21,22,21,65BCCCCBCBCBBBBCBCBCCBBBCBCBBCCC21,3800

 

Response From iTach:

ASCII format: completeir,1:1,1

Hex Format: 63 6F 6D 70 6C 65 74 65 69 72 2C 31 3A 31 2C 31 0D

 

It took about 3 seconds from when I clicked on the send button to when I got the response back.

(This is really a rough estimate using the second hand on the Windows clock on my system.

 

 

4) I was able to get a router from a friend whose teenager bricked it doing a firmware upgrade. :)

Unbricked it, got dd-wrt mini on it, bricked it loading the big build, unbricked it again and was able to get dd-wrt running on it. I am now in the process of configuring the router and playing with the iptables command to do the span port.

 

Sorry it is taking so long to get setup todo the packet capture. Darn day job sure gets in the way of having fun.

 

Regards,

Bruce

Posted

Variables lost feedback...

 

I've been running 3.1.14, and use two variables in a variety of programs. After moving the SD card from one ISY to a replacement a few days ago, everything appeared to work fine. Today I had a program get skipped because the variables were missing. When I went to the Programs tab, the sub-tab for Variables was missing, leaving only Summary and Details. I tried restoring from the backup from the old ISY, but that didn't fix the variables.

 

I upgraded to 3.1.16, and everything is fine. Not only do variables work, but the old variables and programs look just like they did on the old ISY.

 

I don't need help with anything, but wanted to let you folks know about the oddity. I'm guessing something about variables doesn't make it into the normal backup procedure, or something like that.

 

Great work on these products in general. I love my ISY!

Alan

Posted

In all cases that have been reported where the Variables tab was missing, a version of the Admin Console was being used that was before Variables were introduced. The situation was likely resolved when the URL to access the Admin Console was updated to 3.1.16. Check Help | About to be sure both the Firmware line and the UI line (just below the Firmware line) indicate 3.1.16.

Posted

More info about my lost variables...

 

Thanks LeeG. My firmware shows 3.1.16, but UI shows 3.1.14. I'll get that updated too.

 

I think the lost variables are my fault. Since the SD card move seemed to work fine, I may have missed a required step. I just realized that the backup file created before my upgrade to 3.1.16 said 2.8.16 instead of 3.1.14. All features that only work on the betas seemed to be good, such as remotelinc2 functionality, but something still thought the new ISY was on 2.8.16.

 

Thanks,

Alan

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...