• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 1 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Incompatibility in handling of rules:
#11
No idea yet, however some summarized remarks to my tests last night (not starting pilight as daemon, but in debug mode, debuglevel 2).

On one of the tabs i monitor Temp/Humidity/Batt status from 5 tfa devices and i am using the generic label protocol, in combination with the rule engine, to report at which time tfa data was received last. The quality of the RF data link between tfa device and pilight is reliable, therefore missing updates must have another reason.

1. When I started the pilight daemon it all started with pilight crashing and outputting stacktrace data in an endless loop. Needed to kill the process.
2. During the next phase the pilight daemon locked up once Firefox tried to establish an http link, the first update of a generic label took place, but that was it. It was necessary to kill the pilight daemon, CTRL+C was not sufficiant.
3. Cyclic tfa data updates were unreliable and that fact immediately caught my attention, at the same time the web gui was not updated any more the pilight-daemon stopped logging data as well.
4. During the next phase it was possible to get pilight-daemon back to logging data, by pressing one of the buttons for a switch device on the GUI
5. The more often pilight was stopped and started, stability and reliability of data updates improved, upto the current situation that pilight is now running for 20 hours (as a service) ...
 
Reply
#12
Can we check what happens if we just leave the webserver disabled for the time being, just for testing?
 
Reply
#13
Sure. I am currently testing rewrite in my home environment on my Pi-2.

I noticed this morning that some of the device states for generic devices have changed over night.
I use those generic devices to create logical conditions using rules, and only the web interface is used to change the state of those generic devices.
(e.q. if the generic device state IS on, there is a rule switching a real device on or off, if that generic device state IS off, i do not change the state of my real device).
In short, that state should only change whenever i change its state via the webgui, but it magically changes over night, so i assume it gets overwritten somehow (no computer with a web interface was turned on over night ).
This is in sync with two other monitorings,
- i get an e-mail confirmation that a (sunset based condition) rule was activated, and as a result another rule has to switch my devices on, but in reality they are not
 
Reply
#14
@curlymo,

Originally i thought that there is an RF issue present, causing the switches not to turn on/off as intended.
But generic switches do not act as intended either, thus the bug seems to be more subtle, and it does not seem to be GUI related neither.
The same config.json file is working reliably using the development branch.

I have a set of generic switches, and use their state by:
- using rules to store an intended state condition (GEN_SW_x)
- using the WEBGUI to modify an intended state condition (ACT_SW_x)
- using the WEBGUI to visualize the state condition (GEN_SW_x and ACT_SW_x)
(with x a number between 1 and 9)

I use the GUI to set the state of 4 generic switches (ACT_SW_x) to ON or OFF. Rule 3 is using the state of those switches as a logical AND condition to determine whether a real switch should change its state or not.

I use the GUI to monitor the state of real hardware switches (in my case quigg_gt7000 switches); and to turn those switches ON or OFF manually. The special issue with those switches is the long 80000µS footer, that needs to be obeyed.

I have a set of rules.
Rule 1 is turning the state of GEN_SW_1 to the ON or OFF state, based on sunrise/sunset time (ON one hour before sunrise, OFF at sunrise; on at sunset, OFF 5 hours after sunset)
Rule 2 is sending me an email whenever the state of GEN_SW_1 changes
(that e-mail is sent no matter whether the state is changed via the GUI, or via a rule)
Rule 3 is turning multiple real switchs (in my case quigg_gt7000 switches) to the ON or OFF condition, based on the state of GEN_SW_1 and ACT_SW_1)

a)
I can now monitor, that I get the e-mail regarding the state change of GEN_SW_1, indicating that the sunrise/sunset rule was triggered, or the GUI was used to change the state.

b) I can monitor on the WEBGUI, that the state of GEN_SW_1 has changed.
c) I can monitor on the WEBGUI, that for some of the real quigg switches the state has changed as well, but typically one or two of them do not.

In real life,
- the quigg switches typically do not turn on or off, when the state of GEN_SW_1 changes.
- the quigg switches act eratically when i change the state of the GEN_SW_1 switch using the WEBGUI
- they always react when i change the state of the quigg_switch using the WEBGUI.

Due to the fact that everything works as intended with development, I would appreciate of getting some hints of where to look at, to nail the problem down.
 
Reply
#15
Just noticed another bug. Normally i replace config.json with preconfigured files. This time after compiling commit 4a649e7b, i used the config.json.bak file and pilight won't start.
I know for sure that i never configured the string "alarm" for the state.
Code:
"TVState": {
            "protocol": [ "generic_switch" ],
            "id": [{
                "id": 200
            }],
            "state": "alarm"
        },
 
Reply
#16
So, devices magically change state Cool

Can you post the config to see if it does at my setup as well?
 
Reply
#17
@curlymo,

Please find my config.json attached.
I have replaced ip addresses and mail/account names.

I have monitored that occurance only once.
But with that configuration file, i hope that you will be able to recreate some of the other issues.

Hardware/OS Software:
Code:
Linux pi_65 4.1.19-v7+ #851 SMP Sat Mar 5
jessie lite distribution of raspbian (clean install without wheezy history) on a 16GB SD card and filesystem expanded
camera disabled, no overclocking, spi, i2c enabled

Mandatory changes you do need to do to config.json:
Code:
Line 31:
You need to replace the ip address in this line with a valid ip address in order to match it with an existing device.
There are rules checking this ip address.

Line 225, 229, 233, 237, 430:
For some events i do want to get an e-mail notification.
Thus you do need to replace the dummy mail address "dummy_mail@dummymail.dummy" with a valid email address.
There are rules using sendmail to create the e-mails.

Line 431 to 434:
You do need to specify your valid smtp configuration.

Line 438:
I am not using a standard GPIO pin for Sender (Once upon a time, I had 3.3V connected to GPIO 0 and I changed that pin to an output line .... took the output driver to no no land :-(

Changes required for real devices:
Code:
tfa devices - Line 92 to 141:
This is the configuration for 5 tfa (Dostman 32.3200) devices, monitoring temperature and humidity. If you have those, you do need to match id's and channels with your devices.
ATTENTION:
Line 289, 293, 297, 301, 305 need to be changed as well.
I consider those devices to be important, as they generate a pretty decent base load, it should be noted that i pick up some tfa data from my neighbours as well. With the most recent tfa protocol changes, it is for the first time that i am monitoring useful battery indications, before the device turns blank.

quigg_gt7000 devices - Line 182 ff:
Starting from Line 182 there are 4 quigg_gt7000 switches defined.
If you have those, you can change the id and the unit to match them with real ones. There are no further dependencies. I do not recommend to change the device protocol, as that will have an impact on GPIO timing.

Cosmetic changes:
Code:
Line 6, 7, 21, 22:
Change longitude / latitude in order to match sunrise/sunset with your local environment.

I am monitoring different behaviour of of development vs. rewrite branch:

1. quigg_switches:
Currently I can monitor the following incorrect behaviour:
Code:
When i activate/deactivate the GUI switch "LampenZeitschaltUhr" (Line 325):
- branch rewrite: none of the physical switches are acting
- branch development: all physical switches are acting as expected.

On both branches:
The quigg protocol itself is working.
The status of the quigg switches is visualized with the elements at Line 350
The switches will properly turn ON/OFF when i press the buttons associated with the gui elements (Line 350, 355, 360, 365).

Behaviour is different between both branches when i use rules:
a)
Based on the datetime and the sunriseset protocol, I have written some rules that change the state of the generic switch LampenZeitschaltUhr (Line 57). I visualize the results with the GUI element LampenZeitschaltuhr (Line 325), in addition i create an e-mail for remote status monitoring and logging. (The e-mail link a backup method, independant of the VPN tunnel to remote sites, as it requires internet access only). This all seems to work.

b)
Whenever LampenZeitschaltUhr changes its state, i do not want that all quigg switches change their state as well, but only those for which the state of the "associated trigger_switches" is set to ON, Those switches are defined in Line 67 to 85, the corresponding rules are in line 256 to 284, and the GUI elements to change/visualize the state of the "associated trigger_switches" are in line 330 to 345.

This part is not working reliably:
- The state of "associated trigger" is not always obeyed
- The physical switch is not acting in accordance with the change of the state "LampenZeitschaltUhr".

.txt   config.json.txt (Size: 19.14 KB / Downloads: 5)
 
Reply
#18
For the above mentioned configuration, using the development branch, i noticed the following.
Code:
[{"type":8,"devices":["zeit"],"values":"timestamp":1457940730,"dst":0,"second":42,"minute":3,"hour":9,"weekday":2,"day":14,"month":3,"year":2016}},{"type":3,"devices":["sunshine"],"values":{"timestamp":1457931688,"sun":"rise","sunset":18.23,"sunrise":6.33}},
...
{"type":1,"devices":["LampenZeitschaltUhr"],"values":{"timestamp":1457931688,"state":"off"}},
...
{"type":1,"devices":["EG_Buero"],"values":{"timestamp":1457931688,"state":"off"}},
{"type":1,"devices":["EG_Flur"],"values":{"timestamp":1457931689,"state":"off"}},
{"type":1,"devices":["OG_Klavier"],"values":{"timestamp":1457931690,"state":"off"}},
{"type":1,"devices":["OG_Tisch"],"values":{"timestamp":1457931689,"state":"off"}}]

Based on the sequence of rules defined in config.json, i would have expected that the sequence of protocol events for turning the devices off is EG_Buereo, EG_Flur, OG_Klavier, OG_Tisch,
but
looking at the timestamps, it is not.
Thus I have two questions:
1. Can I enforce the sequence of rules to be evaluated ?
2. Can I expect that rules are not passing each other in execution (timewise)?

Other questions that may be important as well:
Is there a possibility, that rules may fail in the current implementation, due to:
3. Time has elapsed (e.q. the comparison of the second has passed by, and due to the fact that the second is part of the logic statement in a rule that condition may no longer be true)
that is part of a rule)?

Remark:
With the current implementation of 10 repeats as a standard, the quigg_protocol has an execution time of pretty close to 1 second, so I would have expected that the timestamps are in order to the evaluation of the rules, the result is put in a queue, and the queue is executed in the order of time(d) events generated. I know that the GPIO subsystem will not mix RF transmissions up, but executes them in sequence, but could it be that the GPIO subsystem handles the event at a different time then stated in the value configuration.
in a different twill it also
This leads to my next two questions:
4. At which time is the timestamp generated ?
5. In the branch rewrite, how is it expected that this behaviour change with the common pool ?

The answer to question 4 is trivial for a single computer environment, but it is getting crucial for an Ad-Hoc Network, as it will be important to know at which point in time an action is triggered / executed and to be able to control such moment in time.
 
Reply
#19
Hey guys,
I'm finally on the rewrite branch (*yay*) and yep I have some strange issues here as well.
Used the existing device/rules/gui configuration. Then when I start pilight and then stop (using pilight-daemon -D), each time a different device state changes to something meaningless.
On first run, it happened to elro_800_switch devices:
Code:
"wzkette": {
                        "protocol": [ "elro_800_switch" ],
                        "id": [{
                                "systemcode": 18,
                                "unitcode": 8
                        }],
                        "state": "connected"
                },
Second run, now it hapened to the kaku_switch_old devices:
Code:
"balkon": {
                        "protocol": [ "kaku_switch_old" ],
                        "id": [{
                                "unit": 2,
                                "id": 0
                        }],
                        "state": "alarm"
                },
Apart from this, there's an error while triggering rules via received protocol signals. Error:
Code:
[May 25 22:51:32:666374] ERROR: rule #10 invalid: trying to compare string variable "kaku_switch_old.unit" to an integer
[May 25 22:51:32:666502] INFO: rule #10 was parsed until: ... kaku_switch_old.unit == 0 AND kaku_switch_old.id == 1 THEN switch DEVICE swi-bedlamp-dima TO on
[May 25 22:51:32:666613] INFO: rule #10 10-kaku-lampe-dima-on was parsed in 0.000521 seconds
Rule:
Code:
"10-kaku-lampe-dima-on": {
                        "rule": "IF kaku_switch_old.state IS on AND kaku_switch_old.unit == 0 AND kaku_switch_old.id == 1 THEN switch DEVICE swi-bedlamp-dima TO on",
                        "active": 1
                },
Did I miss here something?

I will keep looking for more occurences Smile
Should I rather put these issues to new (separate) topics?

EDIT:
I've double-checked the installation. It's the rewrite branch, current commit:
Code:
root@srvpi01:/home/pi/pilight# pilight-daemon -V
pilight-daemon version ea7098d
Seems like the config.json file is updated with wrong values on pilight shutdown. Following is valid for both gui and rules:
- When changing states of an elro_800_switch, the states are changed between "opened" and "closed"
- When changing states of an elro_800_contact, the states are changed between "on" and "off"
- This should be exactly the opposite way.
This is the shell output while switching an elro_800_switch to off:
Code:
[May 26 00:24:55:834315] DEBUG: **** RAW CODE ****
300 900 900 300 300 900 900 300 300 900 300 900 300 900 300 900 300 900 300 900 300 900 300 900 300 900 900 300 300 900 900 300 300 900 900 300 300 900 900 300 300 900 900 300 300 900 300 900 300 10200
[May 26 00:24:55:835484] DEBUG: **** RAW CODE ****
[May 26 00:24:56:254287] DEBUG: successfully send elro_800_switch code
[May 26 00:24:56:255116] DEBUG: possible pollin protocol
[May 26 00:24:56:255237] DEBUG: recevied pulse length of 301
[May 26 00:24:56:255317] DEBUG: caught minimum # of repeats 1 of pollin
[May 26 00:24:56:255392] DEBUG: called pollin parseRaw()
[May 26 00:24:56:255744] DEBUG: possible elro_800_switch protocol
[May 26 00:24:56:255846] DEBUG: recevied pulse length of 301
[May 26 00:24:56:255917] DEBUG: caught minimum # of repeats 1 of elro_800_switch
[May 26 00:24:56:255994] DEBUG: called elro_800_switch parseRaw()
[May 26 00:24:56:256304] DEBUG: possible elro_800_contact protocol
[May 26 00:24:56:256396] DEBUG: recevied pulse length of 301
[May 26 00:24:56:256472] DEBUG: caught minimum # of repeats 1 of elro_800_contact
[May 26 00:24:56:256546] DEBUG: called elro_800_contact parseRaw()
[...]
[May 26 00:24:56:276304] DEBUG: broadcasted: {"message":{"systemcode":28,"unitcode":1,"state":"off"},"protocol":"elro_800_switch","uuid":"0000-b8-27-eb-22d88b","repeats":1}
[May 26 00:24:56:278938] DEBUG: broadcasted: {"message":{"systemcode":28,"unitcode":1,"state":"off"},"origin":"receiver","protocol":"pollin","uuid":"0000-b8-27-eb-22d88b","repeats":1}
[May 26 00:24:56:281736] DEBUG: broadcasted: {"message":{"systemcode":28,"unitcode":1,"state":"off"},"origin":"receiver","protocol":"elro_800_switch","uuid":"0000-b8-27-eb-22d88b","repeats":1}
[May 26 00:24:56:284893] DEBUG: broadcasted: {"message":{"systemcode":28,"unitcode":1,"state":"closed"},"origin":"receiver","protocol":"elro_800_contact","uuid":"0000-b8-27-eb-22d88b","repeats":1}
[...]
(removed unnecessary parts)
Thus I guess that there's a bug in updating the config file. pilight itself is running well though, but in case of a restart (for whatever reasons), pilight won't start because the config is then screwed.
I'm still monitoring for further issues.
 
Reply
#20
1. Can you provide me with a minimal working example that give you this bugs.
2. Does this only happen when closing or also while running or only on closing. You can check this while running through the webserver:
http://x.x.x.x/config
 
Reply
  


Forum Jump:


Browsing: 1 Guest(s)