Lua failure, nonexistent zones

Plugins & Plugin Development Unmaintained
1

Hi Futzle - been playing around with the system for a while now (although still waiting for a new rs232 shorter cable to eradicate any issues caused by noise) and been using the alarm sensors in the house to trigger scenes using your wonderful plugins (combination/timer/virtual switch)

*quick note. firstly i would be happy to pay for the apps above. so if you take donations let me know so i can support your dev work.

my tests/experience has show or resulted the following issues/questions.

1.some times the lua startup takes longer than other times. i estimate it should take 20secs max. is this correct?
2.if partitions are armed (i.e. 1 & 2 out of 3) the lua startup doesnt seem to run correctly - it just freezes indefinitely when i press reload on the interface. if i disarm the partitions it re-activates
3. do pins 7 and 9 affect anything on the plugin and nx 584 (the manual says the are not operational) is that the case for the pluggin also?
4. is it possible to change a sensor type after it has been created? (ie. from motion to door)

thanks

2

It depends on how much is happening in your house. Startup has to get about five messages to the panel and back again. If the panel is trying to tell you about zones changing state while someone is walking around the house, it’ll take longer. Think of a three-year-old telling you all about their busy day while you are trying to get them to bed…

2.if partitions are armed (i.e. 1 & 2 out of 3) the lua startup doesnt seem to run correctly - it just freezes indefinitely when i press reload on the interface. if i disarm the partitions it re-activates

Bug. I will need a Luup log to investigate. Multi-partitions is something I can’t test personally.

3. do pins 7 and 9 affect anything on the plugin and nx 584 (the manual says the are not operational) is that the case for the pluggin also?

Personally I connect them (because that’s what my cable does). No idea if that’s important. The plugin isn’t aware of RTS and CTS; it’s all handled by the OS. The plugin just sees a series of bytes. At the data rates you get with the panel I doubt you could fill the buffer anyway (which is what RTS/CTS control), and since the protocol has retry and checksums it’s unlikely to ever be an issue.

4. is it possible to change a sensor type after it has been created? (ie. from motion to door)

No, once a device has been created on Vera, its type is set in stone. (If you are clever enough to manually edit your Vera’s static data you will know how to circumvent this little lie.) Best thing to do is delete the zone in the plugin’s top-level device’s Zones tab, reload Luup then add it back in with the correct type.

3

futzle - comming back with some logs regarding my problem with consistency. i have put a description in each log.

the main problem is that at times the lua startup runs correctly (as far as i can tell) and at others it doesn’t (basically the running lua startup stays on the interface window indefinetely).

to be specific I might be making a change to the network adding a device etc and when saving which causes the nx-584 plugin to restart i end up having it freeze. this means that the connection could be freezing at other times also.

now more times than not this freeze happens when the alarm is active. changing the status of the alarm somehow (i.e. disarming) actually unfreezes the startup.

from my side I received a new rs 232 ftdi cable this morning and will be replacing the existing cable just incase there is a comms issue there. I also have the pin 7 and 9 back on the defaults currently which shouldnt matter but i will at some point put them back.

any ideas? (by the way can you see any problems with the zwave network from the log?)

Thanks

4

[quote=“alexk, post:3, topic:174815”]comming back with some logs regarding my problem with consistency
[…]
any ideas?[/quote]

… yeah. This is going to be tricky. What I think is happening is that the startup code is sending Partition Status Requests for 1, then 2, then 3, and getting back responses 1, 1, 2, 3. The duplicated 1 is something coincidental, something that the system has volunteered, perhaps a partition-ready state change. Now the plugin is out of sync and keeps sending partition status requests 2, 3, 2, 3, … and gets back responses 3, 2, 3, 2, … Since the responses don’t correspond with the requests, the situation never ends.

The fix is to accept out-of-order responses. I’ll see how tricky that is in the current framework.

I think that your current cable is doing OK from a communication perspective. I’m not seeing any dropouts now.

Edit: Here, try this attached file. I think it will handle the case you posted. I can’t really test this locally because the bug I think it is applies only to multiple partitions. Try hard to break it, and when you do, post the Luup log for me. Thanks. When I’m sure that it hasn’t changed behaviour I’ll update the plugin’s official files. Thought of a bug that my fix introduces. I’ll do it again tonight.

Edit edit: Ok, try this one. Upload it through the usual interface (Apps > Develop Apps > Luup Files). This version insists on enumerating the partitions in order. That’s less efficient, but it’s harder to break. Try to break it and post the log when you do.

(by the way can you see any problems with the zwave network from the log?)

You’re on your own there.

5

hi Futzle, i did as told (I also switched off the auto update function) dont know if this matters.
seems to run instantly now :slight_smile:

will attach a log in a few minutes.
done
thanks!

6

Thanks for testing, alexk. I’ll update the official plugin with the change; it looks safe.

7

so what shall i do? turn auto update back on? (will i see version 66 on mios.apps?)

or

wait until it is updated and perform update so i dont revert to old version?

A

8

I haven’t submitted the update yet, but in your case you can turn auto-update back on now. The file won’t revert because apps.mios.com has no knowledge of your locally different copy. And when it does update, it’ll be the same as the file you’ve already got.

Edit: Update has been submitted. MCV normally approves updates within 48 hours.

You can force your Vera to update to the latest approved version with the URL: http://your_vera_ip:3480/data_request?id=update_plugin&Plugin=1018

9

Version 68 has been submitted. This version avoids the situation reported by HakrWannaB and alexk where zones that don’t exist are updated, resulting in a Lua failure. With this version, these zone status events are just ignored.

10

great! does this fix the issue where a variable wasn’t initiated also?

11

I’m not aware of that issue. Reference?

12

your post at the bottom of the page

http://forum.micasaverde.com/index.php?topic=4060.240

13

Yes, that’s the bug I’m talking about that is fixed in version 68.