RPIEasy

[llevet]

Simplest reason !

I have found the near perfect enclosure for my project and your very good software :

For Raspberry A+, B+ , 2 B & 3 B, 3B+ and new 4B
https://www.hwhardsoft.de/english/proje ... ibox-open/

I would prefer a more large size of prototyping zone but i will make with it.

For Pi Zero
https://www.hwhardsoft.de/english/proje ... ibox-zero/

And Display + swith :
https://www.hwhardsoft.de/english/proje ... ay-shield/

Question: is your _P009_MCP pluging is olso compatible with MCP23008 ? (i think yes but i prefer to ask you)

P.S: I haven't any relation with this compagny !

Thanks.

Ludo.

[enesbcs]

Question: is your _P009_MCP pluging is olso compatible with MCP23008 ? (i think yes but i prefer to ask you)

Originally the MCP23017 asked for implementation, so i done it:
https://github.com/enesbcs/rpieasy/issues/14

In theory the underlaying library supports MCP23008, but i do not have it to test it, and this option is currently hardwired to MCP23017 type.

[llevet]

Ok, i will test it, i think to have one in stock.

Ludo.

[enesbcs]

Ok, i will test it, i think to have one in stock.

As i said it is currently hardwired to 23017 at the init stage, and it wont work with 23008 as they need different init modes. If it is really needed please open a github issue and i will modify the plugin init part and will adding a select option.

[llevet]

Ok, done.

[vidalv]

Hi all, I'm new on RPIEasy, I've installed the package on my PI3 then after starting :

Start.JPG (35.05 KiB) Viewed 105780 times

Now, how to start ESPEasy on web browser ( Chromium) ?
Thanks for help !

[enesbcs]

Hi all, I'm new on RPIEasy, I've installed the package on my PI3 then after starting :
Start.JPG
Now, how to start ESPEasy on web browser ( Chromium) ?
Thanks for help !

As something grabbed port 80 on your RPI, it writes clearly that RPIEasy started on port 8080, so you can reach it from any webbrowser as http://your_raspberry_ip:8080/

[vidalv]

Thanks enesbcs, by putting IP address on menu bar it works fine, thanks !

[bruno iemanon]

I'm missing the "Generic - MQTT Import"-device as in ESPEasy.

Is there a way to import MQTT - values?

[enesbcs]

Is there a way to import MQTT - values?

Both Domoticz MQTT and Generic MQTT controllers supports two way communications in RPIEasy.
For example if you have added a "Generic MQTT controller" and a "Dummy device", than you can send variables to RPIEasy devices from MQTT through the topic: '%sysname%/taskname/valuename/set' and the payload is the value. It is importing from RPIEasy perspective. (certain output devices also supports two way mqtt communication)

It is described in the header:
https://github.com/enesbcs/rpieasy/blob ... GenMQTT.py

[bruno iemanon]

Is there a way to import MQTT - values?

Both Domoticz MQTT and Generic MQTT controllers supports two way communications in RPIEasy.
For example if you have added a "Generic MQTT controller" and a "Dummy device", than you can send variables to RPIEasy devices from MQTT through the topic: '%sysname%/taskname/valuename/set' and the payload is the value. It is importing from RPIEasy perspective. (certain output devices also supports two way mqtt communication)

It is described in the header:
https://github.com/enesbcs/rpieasy/blob ... GenMQTT.py

Thanks for your reply.

I installed a Generic MQTT controller, wich is working fine.
To simplify i use:
Report topic: %valname%
Command topic: %valname%

I also added a "Extra IO - PCF8574"-device with following configuration:
- PCF interrupt: none
- Port: 1
- Data Acquisition: Send to Controller
- Values # Name: 1 RL1
- Interval: 1,0

It does publish every 1 second the value "0" in the topic "RL1". That works fine.

But the value does not change when i publish (manualy with MQTT Lens" the value "1" in the topic "RL1".

I have the same problem when i us a generic dummy device. Any idea what i am doing wrong?

[enesbcs]

To simplify i use:
Report topic: %valname%
Command topic: %valname%

It will never work, with neither devices. Report and command topic can not be the same! I will fix this bug to not let it submit.

This could work for example with an Output helper plugin for standard GPIO's:

%valname%/status
%valname%/set

Otherwise PCF8574 plugin currently supports only changing outputs with three commands: (as in espeasy) PCFGPIO, PCFPULSE, PCFLONGPULSE.
Altough it can be enhanced to work with two way mqtt, i have opened an issue for it.

Currently these RPIEasy plugins can receive MQTT values:
P029 GPIO Output, P033 Dummy, P204,P501,P502,P503,P505,P511
But honestly with Dummy device and Rules you can control anything right now.

UPDATE: in todays commit, MCP & PCF plugins are enhanced to support receiving values through MQTT from the command topic.

[bruno iemanon]

Thanks again for your advie.

But I'm afraid i don't have sufficient knowlegde to fully understand your advice.

I now use following properties:

Generic MQTT controller:
- Report topic: %valname%/status
- Command topic: %valname%/set
Device: Output - Domoticz Output Helper (No feedback)
- Data Acquisition
Send to Controller 1
- Values
# Name
1: "RL1"

I was expecting that when i publish "1" in the topic "RL1/set", the value of the "Device:Output - Domoticz Output Helper" would change into "1". But it doesn't.

Can you also explane what you mean with "UPDATE: in todays commit, MCP & PCF plugins are enhanced to support receiving values through MQTT from the command topic."

[enesbcs]

Thanks again for your advie.

But I'm afraid i don't have sufficient knowlegde to fully understand your advice.

Ok, i'll show you an example. The test RPIEasy system name is "rpieasy" (Config page)
1/ Generic MQTT controller added, with the MQTT broker IP address and
with default report topic ( %sysname%/#/state ) and default command topic ( %sysname%/#/set )

2/ At Hardware/Pinout&Ports a pin is setted to output (in this example i am using GPIO21)

3/ An "Output - Domoticz Output Helper " device is added to GPIO21 and Send to controller enabled. device name: "outdev", value name:"State"

When i am issuing command:
mosquitto_pub -h MQTTSERVERIPADDRESS -t "rpieasy/outdev/State/set" -m 1
Then GPIO21 is went to HIGH state.

When i am issuing command:
mosquitto_pub -h MQTTSERVERIPADDRESS -t "rpieasy/outdev/State/set" -m 0
Then GPIO21 is went to LOW state.

"%valname%/status" is a very interesting approach, it has no information either the target system, nor the target device which has the value. Maybe i can modify the code to support "%tskname%/%valname%" without the system identifier, but it is a very strange request.. do you only have one device connected on the MQTT? Or how do you distinguish between them? (in my example the %sysname% in the front tells the target system, that this message are addressed to it)

Can you also explane what you mean with "UPDATE: in todays commit, MCP & PCF plugins are enhanced to support receiving values through MQTT from the command topic."

It means, that the new RPIEasy version supports the very same method with MCP and PCF plugins. Just make sure to select output type at plugin settings.

[bruno iemanon]

Great, it works!
Thanks a lot for your advice, and for your patiance.

[enesbcs]

Great, it works!
Thanks a lot for your advice, and for your patiance.

No problem. I just started to modify the controller to handle non-standard templates.

[bruno iemanon]

I now used your example to let it work with the device "Extra IO - PCF8574"
i kept the same properties for the mqtt controler:
Report topic: %sysname%/#/state
Command topic: %sysname%/#/set
I created 8 devices of the type "Extra IO - PCF8574"
with the following settings:
I named them RL1, RL2, ..., RL8
Enabled: yes
PCF interrupt: none
port: 1, 2, ...,8
Type: output
Data Acquisition
Send to Controller: 1
Interval: 0
Values
# Name
1 State

With the mqtt-message "1" in the topic rpieasy/RL1(-8)/State/set, the values of the devices RL1 till RL8 changes correctly.
But the outputs of the PCF8574 behafe weerd.
rpieasy/RL1/State/set: PCFGPIO1 goes to high
rpieasy/RL2/State/set: PCFGPIO2 goes to higd and PCFGPIO1 goes to low (value in rpieasy stays "1")
rpieasy/RL3/State/set: PCFGPIO3 goes to high and PCFGPIO2 goes to low (value in rpieasy stays "1")
and so on for all the 8 devices.
So when i send all the 8 mqtt messages with value "1" (retained). All the values in rpieasy are turned into "1" but in reality only PCFGPIO 8 is high and all the rest returned to low.

[enesbcs]

So when i send all the 8 mqtt messages with value "1" (retained). All the values in rpieasy are turned into "1" but in reality only PCFGPIO 8 is high and all the rest returned to low.

Interesting. Did you try the "PCFGPIO,<pin>,<state>" command also?
PCF8574 is a very interesting beast, all pin states are held internally on one byte together. So either the pin state set command failed because the commands arrived to soon and only the last one is accepted, or it is failed to read current pin states before writing new ones. I have a PCF device somewhere in my garage i will test it someday.

[bruno iemanon]

[/quote]
Interesting. Did you try the "PCFGPIO,<pin>,<state>" command also?
[/quote]

I just tested the dummy switch device. device name:RL1-4. Values: RL1, RL2, RL3, RL4
The mqtt part works.
I used some rules to let it interact with the pcf8574.

Rules:
- on RL1-4#RL1=1 do PCFGPIO,1,1 endon

- on RL1-4#RL1=0 do PCFGPIO,1,0 endon

- on RL1-4#RL2=1 do PCFGPIO,2,1 endon

- on RL1-4#RL2=0 do PCFGPIO,2,0 endon

the rules don't work.

the I2C-dependencies are "usable"
The I2C-scan gives a pcf8574 on 0x20. (so i thinks the pcfgpio pins are 1,2,3,...8)

i also tried the command "PCFGPIO,1,1" wich doesn't work.

command output:
20:55:51 : CMD: PCFGPIO,1,1
20:55:51 : PCFGPIO1: name 'Settings' is not defined >> (what does this means?)

any idea what i'm doing wrong?

[enesbcs]

20:55:51 : PCFGPIO1: name 'Settings' is not defined >> (what does this means?)

It means i had a typo in the plugin source code. Fixed in RPIEasy v2.0.003

[bruno iemanon]

I don't know anything about github.
What is the simplest way to update to the newest version?

[enesbcs]

I don't know anything about github.
What is the simplest way to update to the newest version?

There is an Update button in RPIEasy at Tools menu.

[bruno iemanon]

The command PCFGPIO,1,1 is working when used in the tools/command.
problem with the PCF stays the same. (when i send the comman PCFGPIO,2,1 the 2nd output of the PCF goes high, but the 1st output goes low again)

The rules i made, don't seem to work:
on RL1-4#RL1=1 do PCFGPIO,1,1 endon

on RL1-4#RL1=0 do PCFGPIO,1,0 endon

on RL1-4#RL2=1 do PCFGPIO,2,1 endon

on RL1-4#RL2=0 do PCFGPIO,2,0 endon

log:
17:23:01 Event: RL1-4#RL1=1
17:23:05 Event: RL1-4#RL2=1
17:23:07 Event: RL1-4#RL3=1
17:23:07 Event: RL1-4#RL4=1
17:23:08 Event: RL5-8#RL5=1
17:23:09 Event: RL5-8#RL6=1
17:23:09 Event: RL5-8#RL7=1
17:23:10 Event: RL5-8#RL8=1

but now trace of the rules in the log.

[enesbcs]

problem with the PCF stays the same. (when i send the comman PCFGPIO,2,1 the 2nd output of the PCF goes high, but the 1st output goes low again)

In version 2.0.005 i did everything i could to stay sync with "output" statuses. As you know, the PCF8574 is not really made for output, it is done with a simple (weak) PULLUP by the hardware to simulate HIGH. So "output" state may change - without any command as each pin is input in reality - depending what connected to that. I do not really recommend this kind of extender for outputs, MCP23017 ($1.5) is a far more advanced chip. But use PCF if you want, and could. I put mine back to my garage, to the bottom of a shelf...
https://github.com/enesbcs/rpieasy/issues/117

The rules i made, don't seem to work:
on RL1-4#RL1=1 do PCFGPIO,1,1 endon

on RL1-4#RL1=0 do PCFGPIO,1,0 endon

on RL1-4#RL2=1 do PCFGPIO,2,1 endon

on RL1-4#RL2=0 do PCFGPIO,2,0 endon

Please use one command per line (line feeds are your friends), and one condition block for the same value in a ruleset. Like:

Code: Select all

on RL1-4#RL1 do 
 if [RL1-4#RL1]=1
  PCFGPIO,1,1 
 else
  PCFGPIO,1,0
 endif
endon

on RL1-4#RL2 do 
 if [RL1-4#RL2]=1
  PCFGPIO,2,1 
 else
  PCFGPIO,2,0
 endif
endon

[StefanD]

Hi Enesbcs,
do you think that in rpieasy can be implemented an alternative plugin from Tasmota project called 'scripts' to the existing implemented plugin 'rules".
It looks that scripts can handle better some of complex tasks.
Thank you

[enesbcs]

Hi Enesbcs,
do you think that in rpieasy can be implemented an alternative plugin from Tasmota project called 'scripts' to the existing implemented plugin 'rules".
It looks that scripts can handle better some of complex tasks.
Thank you

Sorry, i am using tasmota only for simple on/off sonoff devices, without any 'scripts', so i do not know that. For complex sensor setups i am using exclusively espeasy and rpieasy and i can do everything with rules.
I am afraid it is unlikely that i will learn some new methods for scripting than figure out how to implement a whole new interpreter into rpieasy codebase just to make my life more complicated. It is possible, but unlikely.

[Alan-rpi]

Hi Many thanks for helping RPi users with this GUI My installation went fine!

I'm struggling to get an easy initial test going as I've not found any manuals or guides.

I've defined:

Code: Select all

Hardward Pinouts: Set GPIO 6 (Shutdown Button) to Input
Devices: Defined Generic Input, Name: Shutdown Button, Enabled, 1st GPIO: GPIO 6, Debouce: 300ms, Type: Push Button Active Low, Values/Name: State
Dependencies: Selected Generic MQTT paho-mqtt
Controllers: Defined Generic MQTT, Enabled, Controller: 192.xxx.xx.xx. Port 1883 (default), Report %sysname%/#/state  Command: %sysname%/#/set
				Mode: MQTT (no security), Controller lwl: %sysname%/LWT, Connect: Online, Disconnect: Offline

Now I want to link GPIO 6 to GPIO 13 and send an MQTT message. Do I have to define a rule like this:

Code: Select all

			on ShutdownButton#state do		// GPIO 6
				if [ShutdownButton#state] = 0
					gpio, 13, 1	// shutdown LED on
				else
					gpio, 13, 0	// shutdown LED off
				endif
				Publish RPIEasys/ShutdownButton,ShutdownButton#state
			endon

BTW, I've built some electronics to interface an alarm panel to a RPi4 and to test it and learn Python I wrote a table driven program to test my hardware. So to do the above I would define:

Code: Select all

[6, "ShutdownButton", "input", "falling", 300, 13, "high"],      # Turns on Shutdown Red LED

It strikes me the rules in RPI EAsy could be similarly defined via a GUI table/form, at least to handle simple rules:

Code: Select all

<input device><event><output device><state/message>
e.g. ShutDownButton, falling, ShutDownLED, high
e.g.  ShutDownButton, falling, MQTTClient, myRPI/high
  

Thanks again, RPI Easy is looking promising and could avoid implementing a more complex system like openHAB.

[enesbcs]

I'm struggling to get an easy initial test going as I've not found any manuals or guides.

Its a free software which means that it's free to anyone to write manuals and guides...

I've written a short instructable in english here:
https://www.instructables.com/id/RPIEas ... or-Device/
And a longer one in my mother language here:
https://bitekmindenhol.blog.hu/2019/01/02/rpieasy

Hardward Pinouts: Set GPIO 6 (Shutdown Button) to Input

Please do not use space in device names and value names. I used "Input-Pullup" pin type in my testing as it makes more sense, if it is activated by pulling to GND. (active low)
I hope that GPIO13 is also defined as output at Pinout.

Devices: Defined Generic Input, Name: Shutdown Button, Enabled, 1st GPIO: GPIO 6, Debouce: 300ms, Type: Push Button Active Low, Values/Name: State

In case the status did not change you can lower debounce to 50 or 100ms. For last resort try to enable 1/10sec periodic checking.

Code: Select all

on ShutdownButton#State do
 if [ShutdownButton#State] = 0
  gpio, 13, 1
 else
  gpio, 13, 0
 endif
 Publish RPIEasys/ShutdownButton,[ShutdownButton#State]
endon

I've tested this code just now and works as expected. ESPEasy rules are well documented:
https://www.letscontrolit.com/wiki/inde ... rial_Rules

[Alan-rpi]

Many thanks for your reply and useful hints

I did try my code before posting and the console indicated that the button was pressed, but nothing else.

If there are syntax errors in the rules, do they appear on the console?

You say "For last resort try to enable 1/10sec periodic checking.". That implies RPI Easy is polling the pins for state change rather than setting up GPIO.add_event_detect. Is that correct? I'm a bit worried about my Pi 4 overheating if it is running 24/7. They seem to have a bit of a reputation in this area.

Tomorrow I will make your suggested changes and try again.

Best wishes, Alan

[enesbcs]

If there are syntax errors in the rules, do they appear on the console?

"Debug level" console logging gives some idea what is happening in the background. I did not implemented the full rule engine, interpreter simply forwards commands to plugins (which returns only simple False in case of error), or conditional checks to python eval() function (which returns true or false).
The code i've sent is working, the code you've posted earlier missed some [].

You say "For last resort try to enable 1/10sec periodic checking.". That implies RPI Easy is polling the pins for state change rather than setting up GPIO.add_event_detect. Is that correct? I'm a bit worried about my Pi 4 overheating if it is running 24/7. They seem to have a bit of a reputation in this area.

The default behaviour is to use add_event_detect, except when you CHECK 1/10 periodic check than it will use periodic check. Periodic checking is a fallback method only, because in my experiences add_event_detect did not work always, especially if you use debounce.. you will see.

[enesbcs]

1.Preparation
Prepare an esp-f module of Shenzhen Doit Technology Co., Ltd., or a nodemcu of Doit Technology Co., Ltd

This is neither RPIEasy nor Raspberry PI related, you have missed the topic.
(Honestly this post is not even ESPEasy related...)

[TD-er]

The same post has been posted on some other fora: https://www.google.com/search?rlz=1C1GC ... CAs&uact=5

Not sure what to think of this.
Is it meant as a place holder so the post can later be changed?
In the other pages there is a link included which does refer to lots and lots of javascript links.

[Alan-rpi]

Hi. Thanks for your help. I'm making progress . I now have 2 issues:

Issue 1: MQTT: I amended the rules to state

Code: Select all

Publish "RPIEasy/ShutdownButton",[ShutdownButton#State]

The log says

Code: Select all

19:57:47: CMD: Publish "RPIEasy/ShutdownButton",0   (or 1)

but nothing is getting through. I'm using Docker/Mosquitto and monitoring with MQTT.fx. I can send messages via a Putty window/CLI

Code: Select all

docker exec -it mosquitto mosquitto_pub -d -t "RPIEasy/ShutdownButton" -m "Hello world!"	

and that gets through to MQTT.fx.

Looking at the RPI Easy Controller I note that:
1. I've no Controller User:/Controller Password: set
2. I've no Server certificate file:

My Mosquitto / MQTT.fx are running without SSL and the Client ID is set to "MQTTfx client" .

Does RPI Easy always run with SSL? (i.e. I need to generate and set certificates) and set User/Pwd both in RPI Easy and Mosquitto?

Issue 2: Erratic state of Push Button GPIO 6

This push button is hard wired to be normally High and goes Low when pressed.

I note that when I press AND hold the button that RPi Easy displays

Code: Select all

20:23:34: CMD: Publish "RPIEasy/ShutdownButton",0
20:23:34: CMD: Publish "RPIEasy/ShutdownButton",1

Sometimes it switches static state and goes from 1 to 0. I know that cheap buttons are erratic!

When I tested my hardware with my own Python script I set the add_event to detect Falling. But in RPi Easy one cannot state the event type. I suspect you are using Both. [ I noticed with my own script that using Both the program can get out of sync].

Do you have any suggestions please.

Thank you
Alan

[enesbcs]

Issue 1: MQTT: I amended the rules to state

Code: Select all

Publish "RPIEasy/ShutdownButton",[ShutdownButton#State]

I've used this:
Publish RPIEasy/ShutdownButton,[ShutdownButton#State]
and it arrives according to mosquitto_sub ... i do not know what do you want exactly with those apostrophes, neither ESPEasy Publish nor RPIEasy Publish needs that.

Does RPI Easy always run with SSL? (i.e. I need to generate and set certificates) and set User/Pwd both in RPI Easy and Mosquitto?

SSL, password and other stuff is optional. I am using RPIEasy without any of that in my local network.

When I tested my hardware with my own Python script I set the add_event to detect Falling. But in RPi Easy one cannot state the event type. I suspect you are using Both. [ I noticed with my own script that using Both the program can get out of sync].

Yes "BOTH" is hardwired in the code. Although i can add a new select box in the P001 plugin to let it customize. If you have a github account, please add an issue when you have a development idea.

[Alan-rpi]

That was a quick reply, thank you.

i do not know what do you want exactly with those apostrophes, neither ESPEasy Publish nor RPIEasy Publish needs that.

I'll remove the quotes, I was just trying anything to get it to work. I'll need to do some more thinking and see if there are MQTT monitoring tools.
UPDATE: Removed the quotes and it is now working! I can assure you I initially did not have quotes.

SSL, password and other stuff is optional. I am using RPIEasy without any of that in my local network.

That's good to know and will save time learning and implementing certificates - looks long winded.

Yes "BOTH" is hardwired in the code. Although i can add a new select box in the P001 plugin to let it customize. If you have a github account, please add an issue when you have a development idea.

Will do. Hopefully it is an easy change.

Alan

[Alan-rpi]

I have spent a few hours experimenting and have drawn 2 conclusions:

1) Comments cause erratic behaviours.
Comments on their own line at the start or end of a rule are OK.
Comments at the end of a rule statement causes the rule to not work or to work erratically.

Code: Select all

// comment OK
on ShutdownButton#state do   // comment not OK
    if [ShutdownButton#state] = 0   // comment not OK
        gpio, 13, 1  // comment not OK
    else 
        gpio, 13, 0  
    endif
    Publish RPIEasy/ShutdownButton,[ShutdownButton#state]
endon

I will raise an issue.

2) Pressing a push button and holding it down (the button is normally High) causes a double state change.

Code: Select all

on ShutdownButton#state do   
    if [ShutdownButton#state] = 0  
        gpio, 13, 1 
    else 
        gpio, 13, 0 
    endif
    Publish RPIEasy/ShutdownButton,[ShutdownButton#state]
endon

This causes:

Code: Select all

Press and Hold
15:39:41: Event: ShutdownButton#State=0
15:39:41: CMD: gpio, 13, 1
15:39:41: CMD: Publish RPIEasy/ShutdownButton,0
15:39:42: Event: ShutdownButton#State=1
15:39:42: CMD: gpio, 13, 0
15:39:42: CMD: Publish RPIEasy/ShutdownButton,1
Release

Here the output LED went from On to Off while pressed.
Sometimes Releasing causes a state change (probably due to bounce). Thereafter Pressing and Hold causes the LED to go from 0 to 1.

The expected behaviour is that pressing the button (i.e. input goes Low) makes the LED go On but the LED should only go out when the Button is Released.

I will raise an issue with a fuller log.

As previously discussed, having the option to state that an event is triggered by rising/falling may solve the problem but it may not: there still may be double state changes while the button is pressed.

[budman1758]

1) Comments cause erratic behaviours.
Comments on their own line at the start or end of a rule are OK.
Comments at the end of a rule statement causes the rule to not work or to work erratically.

Try using a hashtag # symbol for comments. On RPIEasy the rules are interpreted using python. (I believe)
I was having rules issues and tried that and it seems to have fixed things here.

[Alan-rpi]

Try using a hashtag # symbol for comments. On RPIEasy the rules are interpreted using python. (I believe)
I was having rules issues and tried that and it seems to have fixed things here.

Will do. I was following the guide here
https://www.letscontrolit.com/wiki/inde ... es#Comment
which uses // for comments (as referred to by enesbcs

[enesbcs]

Comments at the end of a rule statement causes the rule to not work or to work erratically.

Yep. Honestly i never comment on my own rules to myself, so i never saw this error yet.

As previously discussed, having the option to state that an event is triggered by rising/falling may solve the problem but it may not: there still may be double state changes while the button is pressed.

Sure, i can add an option to rising or falling, but how the code will be notified about the opposite change? This is the reason i am using "both".
Bouncing is an interesting thing, when stability is critical i am using the 1/10s method as i mentioned earlier, as event_handler misses occasionally.

[enesbcs]

Try using a hashtag # symbol for comments. On RPIEasy the rules are interpreted using python. (I believe)

You are right, "IF" conditions forwarded directly to python interpreter, so # will work on these lines.
On the other hand, custom commands are not aware of these.

Standard // comments are now skipped from processing, just be sure to write a space before them.

[enesbcs]

https://www.letscontrolit.com/wiki/inde ... es#Comment
which uses // for comments (as referred to by enesbcs

Indeed.

ESPEasy rules are well documented:
https://www.letscontrolit.com/wiki/inde ... rial_Rules

Which is true, ESPEasy rules are well documented. And around 90% of them is implemented in RPIEasy.
// comment support added in RPIEasy 2.0.045

[Alan-rpi]

Sure, i can add an option to rising or falling, but how the code will be notified about the opposite change? This is the reason i am using "both".
Bouncing is an interesting thing, when stability is critical i am using the 1/10s method as i mentioned earlier, as event_handler misses occasionally.

In my Python script I set the INPUT events using

Code: Select all

CODE SNIPPET - program is table driven        
          callback = lambda GPIO_pin, arg0 = GPIO_pin, arg1 = GPIO_name, arg2 = GPIO_detect, arg3 = GPIO_bounce, arg4 = Output_GPIO, arg5 = Output_Action: GPIO_Interrupt(arg0, arg1, arg2, arg3, arg4, arg5) 
            if GPIO_detect == "rising":
                GPIO.add_event_detect(GPIO_pin, GPIO.RISING, callback, bouncetime=GPIO_bounce)
            elif GPIO_detect == "falling":
                GPIO.add_event_detect(GPIO_pin, GPIO.FALLING, callback, bouncetime=GPIO_bounce )
            elif GPIO_detect == "high":
                GPIO.add_event_detect(GPIO_pin, GPIO.HIGH, callback, bouncetime=GPIO_bounce )
            elif GPIO_detect == "low":
                GPIO.add_event_detect(GPIO_pin, GPIO.LOW, callback, bouncetime=GPIO_bounce )
            else:  # both
                GPIO.add_event_detect(GPIO_pin, GPIO.BOTH, callback, bouncetime=GPIO_bounce )
       

Then the interrupts are handled:

Code: Select all

    CODE SNIPPET
       if not (GPIO_detect == "both"): # i.e. high, low, rising or falling
            if Output_Action == "high":
                GPIO.output(Output_GPIO, GPIO.HIGH)
            else:   # low
                GPIO.output(Output_GPIO, GPIO.LOW)
        else:   # both rising and falling, so swap current state of Output GPIO
            if GPIO.input(Output_GPIO): # if high then set low 
                GPIO.output(Output_GPIO, GPIO.LOW)
            else:                       # is low so then set high
                GPIO.output(Output_GPIO, GPIO.HIGH)

So you see for "both" I swap current state of Output GPIO. I agree that bouncing can cause problems. That's why for my push button (which is normally High) I set the event to catch Falling. Any bounce will create 2 Falling events in quick succession and will cause the event action to occur twice (e.g. light LED, turn on relay) but it will be the same Falling action and not opposite actions as with Both.

UPDATE: Maybe swapping states is illogical. Using a real world example. I plan to interface to an alarm panel. An output from the panel will go high when the alarm is activated and low when cleared. I will have to use Both, so it makes sense to output the input state. So on going high the Easy system reports a 1 and when it goes low reports a 0. If people want the opposite state they just test for the opposite state in their rules. Using Both on the panel output should not be influenced by bounce as it is an electronic switch. For push buttons rising/falling is better.

[Alan-rpi]

// comment support added in RPIEasy 2.0.045

That was quick! Thank you. I will download and try. What's the best way to update and not loose my configuration?

[budman1758]

That was quick! Thank you. I will download and try. What's the best way to update and not loose my configuration?

Every time I have updated I have used the update function found on the tools page. So far it has never corrupted my config. Of course. your mileage may vary.
On the same page is an option to download a json settings file and the rules can be downloaded from the "files" page.

[Alan-rpi]

Update went fine. And I see we now have Rising and Falling on the Devices. Thank you for these changes. Yes, I forgot there was an Update function under tools. Now I've used it then hopefully I will remember for next time!

With more experiment I'm seeing how RPi Easy works.

With the Push Button and using Falling I'm still getting 2 events when the button is pressed and held down but with an "if" test in the Rules I can ignore the 2nd event:

Code: Select all

// This rule is activated when Push Button GPIO 6 changes state
// Push Button circuit is normally High and goes Low when pressed
on ShutdownButton#state do        // Event 
    if [ShutdownButton#state] = 0   // Pushed goes Low
         gpio, 13, 1                             // Turn on Red LED
        Publish RPIEasy/ShutdownButton,[ShutdownButton#state]
   endif
 endon

Code: Select all

21:20:18: Event: ShutdownButton#State=0
21:20:18: CMD: gpio, 13, 1
21:20:18: CMD: Publish RPIEasy/ShutdownButton,0
21:20:19: Event: ShutdownButton#State=1        <<<<<<<<<<<<<<< 2nd event even though push button held down

I've also set up a test with input that goes High on an Alert and then goes Low when cleared. Here I used Both:

Code: Select all

// This rule is activated when GPIO 24 changes state
// It is normally Low
on GPIO24Orange#state do        // Both Event
    if [GPIO24Orange#state] = 1   // Goes High
        gpio, 13, 1                             // Turn on Red LED
    else                                           // Goes Low
        gpio, 13, 0                             // Turn off Red LED
    endif
    Publish RPIEasy/GPIO24Orange,[GPIO24Orange#state]
endon

giving

Code: Select all

21:20:55: Event: GPIO24Orange#State=1
21:20:55: CMD: gpio, 13, 1
21:20:55: CMD: Publish RPIEasy/GPIO24Orange,1
...............
21:21:03: Event: GPIO24Orange#State=0
21:21:03: CMD: gpio, 13, 0
21:21:03: CMD: Publish RPIEasy/GPIO24Orange,0

For the GPIO24 I defined it as an Input of type Normal Switch but I was perplexed by the statement on the form:

Note: Use only normal switch for output type, i warned you!

I'm wary of setting an input as output - I don't want to cook my pi! And what is the warning?

[Edit] Just to be clear, I'm happy with the way the GPIO24 example is working

Alan

[Alan-rpi]

Moving on to looking at other functionality that is needed for my project.

I need to send emails up to 3 destinations: 1) my personal email a/c; 2) SMS services 3) phone alert service

RPi Easy has up to 4 email notifications but the message body seems fixed. I need to varying the message Body according to the event and maybe even the Subject (to indicate say urgency)

I looked at the Rules hoping for a SMTP command a bit like the MQTT Publish. I thought the SendTo might be SMTP but it's not

Is there a way?

Also, how are the existing Notifications used - I couldn't see any reference to them.

[enesbcs]

For the GPIO24 I defined it as an Input of type Normal Switch but I was perplexed by the statement on the form:

Note: Use only normal switch for output type, i warned you!

I'm wary of setting an input as output - I don't want to cook my pi! And what is the warning?

If you use Pushbutton type in the plugin when the pin mode is "output" than it will not work as expected. (switch mode is the default) Changing input to output will not fry your Pi except if you drive a HIGH level in front of an incoming current without limiting resistor i think.
Also event_notification will only work when the pin is "input" type.

I need to send emails up to 3 destinations: 1) my personal email a/c; 2) SMS services 3) phone alert service

You can use Telegram notification for you phone.
For SMS services, i guess you need some serial GSM module with a SIM card. And of course you have to code the new notification plugin.

RPi Easy has up to 4 email notifications but the message body seems fixed. I need to varying the message Body according to the event and maybe even the Subject (to indicate say urgency)

You can add multiple e-mail notificators with different subject and body.

I looked at the Rules hoping for a SMTP command a bit like the MQTT Publish. I thought the SendTo might be SMTP but it's not
Is there a way?
Also, how are the existing Notifications used - I couldn't see any reference to them.

The body message can be changed on the fly with notify command.
Notify <position>, [message_in_the_body]
https://www.letscontrolit.com/wiki/inde ... ifications

[Alan-rpi]

Thanks for your help.

For SMS services, i guess you need some serial GSM module with a SIM card. And of course you have to code the new notification plugin.

That is the standard way but needs expensive hardware and a mobile data account with a usual 10p/message or more. For infrequent use there are SMS gateway providers. You send them an email and they then send the body as an SMS message at a typical cost of 5p or less. Some offer SOAP and HTTPS interfaces but email is simpler but is potentially subject to delays.

Similarly for mobile alerts there are gateway providers but the Telegram option is probably better.

The body message can be changed on the fly with notify command.
Notify <position>, [message_in_the_body]
https://www.letscontrolit.com/wiki/inde ... ifications

Thanks for the link - I don't think I would have found it as the page seems to be orphaned. I did note that

the Email-Notification inside ESPEasy does not support SSL

Does that apply to RPi Easy? I think I read that RPi Easy is written in Python and I note that Python supports smtplib.SMTP_SSL().

Alan

[enesbcs]

Thanks for the link - I don't think I would have found it as the page seems to be orphaned. I did note that

the Email-Notification inside ESPEasy does not support SSL

Does that apply to RPi Easy? I think I read that RPi Easy is written in Python and I note that Python supports smtplib.SMTP_SSL().

If you open the notification settings, you will see a Protocol select box, where SSL is selectable.
ESP8266 has very little RAM and storage space, so SSL support is a little tricky, but Raspberry PI has a full Linux OS and proper SSL support libraries preinstalled.

[budman1758]

There is a way to send text to your phone via email. See this web page for detail.
https://www.digitaltrends.com/mobile/ho ... l-account/
I've used this before. Seems to work ok.