Release 2.1 Gateway and LCD node added

[computourist]

Some new code on: github.com/computourist/RFM69-MQTT-client

A new end node is added. I intend to use it as a console.

It has an LCD display and two buttons. Text for the display can be sent over MQTT (generated by openhab).

Pressing the buttons generates an MQTT message, that can be used to trigger actions by Openhab.

- Computourist

[johno123]

Awesome - I was thinking about starting on an LCD interface with your original end node code. I'll give it a try tonight!

[camblonie]

This is a great node with tons of utility. I'm missing how to publish some text though. I've tried many combinations to demonstrate a publish based on a button on the UI. OH Designer doesn't like the items I created. Does the item need to contain the actual message or do I need to setup a variable?

**items
String send_lcd "strg lcd" (ALL) {mqtt=">[mymosquitto:home/rfm_gw/sb/node02/dev72:2:1]"}
Switch itm_lcd_btn "LCD thing" <blank>

**rule
rule "Pub to LCD"
when
Item itm_lcd_btn received update
then

sendCommand(send_lcd,"display")
end

**sitemap
Switch item=itm_lcd_btn mappings=[OFF="Lcd tst"]

[computourist]

Feb 22, 2015 20:05:02 GMT camblonie said:

This is a great node with tons of utility. I'm missing how to publish some text though. I've tried many combinations to demonstrate a publish based on a button on the UI. OH Designer doesn't like the items I created. Does the item need to contain the actual message or do I need to setup a variable?

**items
String send_lcd "strg lcd" (ALL) {mqtt=">[mymosquitto:home/rfm_gw/sb/node02/dev72:2:1]"}
Switch itm_lcd_btn "LCD thing" <blank>

**rule
rule "Pub to LCD"
when
Item itm_lcd_btn received update
then

sendCommand(send_lcd,"display")
end

**sitemap
Switch item=itm_lcd_btn mappings=[OFF="Lcd tst"]

Hi Camblonie,

The syntax for displaying a line on the LCD is:


topic home/rfm_gw/sb/nodexx/dev72  
message y:messagetext
where y is the linenumber.

As an example the way I display temperature on the display:

Items:

Switch switch_01 "LED output" {mqtt=">[mosquitto:home/rfm_gw/sb/node03/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node03/dev16:command:OFF:OFF]"}
Number Temp "Temperature [%.1f °C]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev48:state:default]"}
Number HUM "Humidity [%.1f %%]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev49:state:default]"}
Number RSSI "RSSI [%d DB]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev02:state:default]"}
String getRSSI "get rssi" {mqtt=">[mosquitto:home/rfm_gw/sb/node03/dev02:command:*:default]"}
String LCDprint "LCD print" {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev72:command:*:default]"}
and rules:


import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var String line = "0:Temperature is "

rule "refresh RSSI"
when
Time cron "0 0/5 * * * ?"
then
sendCommand(getRSSI, "READ")
end

rule "write LCD"
when
Time cron "0 0/1 * * * ?"
then
sendCommand(LCDprint, line + Temp.state)

end
In this case the Item LCDprint holds the reference to device 72 for writing the string;
The rule "write LCD" writes temperature and updates every minute. It uses the value of item Temp to read actual temperature.
The variable 'line' holds the linenumber for the first line (0), where the temperature is displayed.

- Computourist

[etrombly]

Hi, I really liked the way your gateway was setup, but I wanted everything to run just on a raspberrypi. So I ported your gateway to python. In the pdf you included you have ranges for device ids, do you have it further broken down with which one's you've already implemented? I'd like to keep mine in sync. I'm planning on making a remote outlet first, so I was going to use device id 17 for it, it looks like that's a relay in your pdf. Thanks again for writing this, I'll post a link to my version once I've tested it a little more.

[selcouth]

Feb 27, 2015 4:17:18 GMT etrombly said:

Hi, I really liked the way your gateway was setup, but I wanted everything to run just on a raspberrypi. So I ported your gateway to python. In the pdf you included you have ranges for device ids, do you have it further broken down with which one's you've already implemented? I'd like to keep mine in sync. I'm planning on making a remote outlet first, so I was going to use device id 17 for it, it looks like that's a relay in your pdf. Thanks again for writing this, I'll post a link to my version once I've tested it a little more.

Would you mind sharing your python port of computourist's gateway? I've wanted to check it out but I'm limited to a Pi on my gateway end as well.

[etrombly]

Feb 27, 2015 4:27:48 GMT selcouth said:

Feb 27, 2015 4:17:18 GMT etrombly said:

Hi, I really liked the way your gateway was setup, but I wanted everything to run just on a raspberrypi. So I ported your gateway to python. In the pdf you included you have ranges for device ids, do you have it further broken down with which one's you've already implemented? I'd like to keep mine in sync. I'm planning on making a remote outlet first, so I was going to use device id 17 for it, it looks like that's a relay in your pdf. Thanks again for writing this, I'll post a link to my version once I've tested it a little more.

Would you mind sharing your python port of computourist's gateway? I've wanted to check it out but I'm limited to a Pi on my gateway end as well.

Here it is github.com/etrombly/gateway . I've only tested the gateway node itself (uptime mostly), so if you have any issues submit a bug report.

edit: you can change the network id, key, and frequency at the top of the file

[computourist]

Feb 27, 2015 4:17:18 GMT etrombly said:

Hi, I really liked the way your gateway was setup, but I wanted everything to run just on a raspberrypi. So I ported your gateway to python. In the pdf you included you have ranges for device ids, do you have it further broken down with which one's you've already implemented? I'd like to keep mine in sync. I'm planning on making a remote outlet first, so I was going to use device id 17 for it, it looks like that's a relay in your pdf. Thanks again for writing this, I'll post a link to my version once I've tested it a little more.

Good effort, now you can choose where to run the gateway code without need for changes in end-nodes.

Device ID's indicate the way the data in handled in the gateway. Any end-node could have a different implementation of a device: the combination nodeID/deviceID points to a specific function.
F.E:
- device 16 could be a relay in node 1 and an indicator LED in node 2.
- device 32 could be a PIR sensor in node 3 and a button in node 2.
- device 72 sends text messages for an LCD in node 5 and wireless control commands in device 3.

This allows the greatest flexibility in end nodes, without constantly changing the gateway code.
The ultimate binding between the actual device and the control program is done in the config of Openhab (or any other control program).

The device ID's implemented in the gateway right now are:

0 - 16 Node system devices (they need special and unique treatment in the gateway)
16 - 32 Binary output (LED, relay)
32 - 40 Integer output (pwm, dimmer)
40 - 48 Binary input (button, switch, PIR-sensor)
48 - 64 Real input (temperature, humidity)
64 - 72 Integer input (light intensity)

72 string: transparant string transport

73 - 90 Special devices not implemented in gateway (yet)

Currently defined error messages are:
90 error: Tx only: error message if no wireless connection
91 error: Tx only: syntax error
92 error: Tx only: invalid device type
99 wakeup: Tx only: sends a message on node startup

I have the following end-nodes working:

- DTH end node with temperature, humidity, binary output, binary input
- LCD end node with display of text sent over device 72 (string) and two binary inputs (buttons)
- Wireless remote control node that transmits 433Mhz commands to commercial wireless switches; uses device 72 for transmission of command code

I am planning to design an end node for RFID key detection, sending the TAG UID over device 72 (string).

I noticed that the current implementation of a binary input (it just sends a message when pushed) does not handle well in Openhab.
I will probably change it soon to a mode where an "ON" message is sent when pushed, and an "OFF" message some time later.
The gateway code needs to be changed for that.

Hope this helps.....

- Computourist

[etrombly]

Thanks, that makes sense. I initially thought you were keeping all leds as dev16, relays dev17, etc.

[computourist]

Feb 27, 2015 16:28:00 GMT etrombly said:

Thanks, that makes sense. I initially thought you were keeping all leds as dev16, relays dev17, etc.

No, for the gateway it is transparant, as long as the function (and gateway handling) of devices stays the same.
This gives you an optimum in flexibility without having to update the gateway code constantly...

[etrombly]

selcouth, if you had downloaded my code previously please do a git pull before you try using it. There were a few problems in how I use unpacking the data. It's all working now. I have a node written for a power relay now, which I'll push back to computourist's repo once it's cleaned up.

[daenny]

Hi etrombly,
Thanks for your port of the lib to python. I tried running it now, but I get stuck at getting the gateway to work. I now tried your example.py in the RFM lib and the code stops at "sending blah to 0x02". The temperature is read (return values from 47-52 at the moment) and than it loops infinitely. Do you have an idea what the issue could be?
I am using the RFM69HW 868mhz version on a Raspberry Pi B (non plus) and connected it as you wrote on your github.

Btw. I tried to lower the transmission power (since I thought that might be problem that the RPi cannot provide enough power on 3.3 V) and your RFM lib gave an error. In that function you forgot the "self" before readReg (Line 163). But even with the lower power, it still hangs at the sending.
Any help would be appreciated. Thanks

EDIT: Nevermind, I did not connect the DIO pin to GPIO24 but to pin 24...

[etrombly]

So is it working for you now? The temp needs to be calibrated for your local area, it seems like it's not very accurate . You can change the calibration factor when calling readTemperature, it adds it to the measurement. If the temp is too high you can use a negative number. I may start another thread for the python client.

I'm debating on changing the wireless library though. The ack's have not been reliable, the way the library is written you need to receive the ack for a message immediately after you send it. If you receive another message before the ack, it thinks the message was not acknowledged. It would break compatibility with moteino's though, which I was trying to avoid.

[daenny]

Yeah it is working more or less. The raspberrypi is at 100% CPU usage, when running the code and a lot of messages are not received. But I thought the reason might be the sender (I tried a 5V arduino uno r3, and a 5v nano, see my other thread) which are not really working reliably in my feeling.
I tried sending using a stripped down code from temperature node on the arduinos (i.e. sending fixed temperature valued) and like 30% of the messages get through to the raspberry pi (distance between them only 10cm...). I tried playing around with the wait for ACK values, but that did not change a lot. I thought to wait now for the Buono clones so that I actually have 3.3v arduinos to be sure that those are not the problem.
Also when I try to ask for a sensor update via mosquitto, e.g. publish a "READ" southbound to node2/dev00 this usually does not work. I put some debug prints in the gateway to be sure that it gets processed, and most of the time the request is also received at the arduino, but the result is never received at the raspberry pi.
I won't have much time to work on this project for the next two weeks, and by then the Buonos should have arrived. After that I will try again.

[etrombly]

It is more than likely the python RFM69 library, not the arduino. I've been having similar issues. The messages are actually being received, but the ack isn't acknowledged. I've been testing this on a pi2, so the performance hasn't been an issue. I'll continue looking into improving the reliability of the library, but am pretty busy the next few weeks as well.

[daenny]

I have never done it myself, but do you think it would be an option to write python wrappers for the C-library? I generally like the python only approach, but if we could wrap the C code into python, the library would be the same/very similar as for the arduinos. We also do not need too many functions, mainly the initialize and the send, i guess?

[etrombly]

I've been looking into it. I might give it a go. It'll probably take me a while, since I haven't written one before. Good chance to learn though.

I've updated the python library with a few changes to make it more reliable....seems to be working about 60-70% of the time now rather than 30-40%. Still not really acceptable, but an improvement. If you're using my relay device code, I've updated that as well.

[ragoth]

Feb 23, 2015 20:24:54 GMT computourist said:

Feb 22, 2015 20:05:02 GMT camblonie said:

This is a great node with tons of utility. I'm missing how to publish some text though. I've tried many combinations to demonstrate a publish based on a button on the UI. OH Designer doesn't like the items I created. Does the item need to contain the actual message or do I need to setup a variable?

**items
String send_lcd "strg lcd" (ALL) {mqtt=">[mymosquitto:home/rfm_gw/sb/node02/dev72:2:1]"}
Switch itm_lcd_btn "LCD thing" <blank>

**rule
rule "Pub to LCD"
when
Item itm_lcd_btn received update
then

sendCommand(send_lcd,"display")
end

**sitemap
Switch item=itm_lcd_btn mappings=[OFF="Lcd tst"]

Hi Camblonie,

The syntax for displaying a line on the LCD is:


topic home/rfm_gw/sb/nodexx/dev72  
message y:messagetext
where y is the linenumber.

As an example the way I display temperature on the display:

Items:

Switch switch_01 "LED output" {mqtt=">[mosquitto:home/rfm_gw/sb/node03/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node03/dev16:command:OFF:OFF]"}
Number Temp "Temperature [%.1f °C]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev48:state:default]"}
Number HUM "Humidity [%.1f %%]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev49:state:default]"}
Number RSSI "RSSI [%d DB]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev02:state:default]"}
String getRSSI "get rssi" {mqtt=">[mosquitto:home/rfm_gw/sb/node03/dev02:command:*:default]"}
String LCDprint "LCD print" {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev72:command:*:default]"}
and rules:


import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var String line = "0:Temperature is "

rule "refresh RSSI"
when
Time cron "0 0/5 * * * ?"
then
sendCommand(getRSSI, "READ")
end

rule "write LCD"
when
Time cron "0 0/1 * * * ?"
then
sendCommand(LCDprint, line + Temp.state)

end
In this case the Item LCDprint holds the reference to device 72 for writing the string;
The rule "write LCD" writes temperature and updates every minute. It uses the value of item Temp to read actual temperature.
The variable 'line' holds the linenumber for the first line (0), where the temperature is displayed.

- Computourist

[ragoth]

Hi Camblonie, I have copied and pasted the Items and rules in the relevant files of configuration folder as suggested by you . The LCD node displays "Startup LCD V2.1, DEBUG mode !!!" in the beginning. At the serial port "LCD Node Software Version LCD V2.1, Transmitting at 433 Mhz... message 99 sent... message 2 sent... message 2 sent..." and it keep repeats. No change in LCD Display. Please advice, where I am wrong to test the LCD Node. Thank you in advance.

[camblonie]

Ragoth,
I tore down my lcd node recently so I cant see what the startup message was. I usually leave debug on and I don't remember seeing it on the display. Try with debug off. There is some node that normal operation won't work w debug and it's probably this one.

[computourist]

Hi ragoth,

You have to send a string to the node to be displayed on the LCD.
What you describe is normal: message 99 is node wakeup and message 2 is RSSI value sent regularly.

[ragoth]

Dear All, My problem with LCD node is: although the LCD is 4 line, it displays data, only in 2 lines either top 2 lines or bottom 2 lines. The following code should display 4 lines of data, but displays first 2 lines only. The second set of code below displays the 3rd and 4th line only. but never all 4 lines. request help. I showed a part of Rules code, relevant to the issue to make it short. if someone needs full, I will post.
CODE 01:
import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var Timer timer
var String line1 = "0:Battery Volts "
var String line2 = "1:Radio Signal dB "
var string line3 = "2:Rain Level "
var string line4 = "3:Radio Signal "


rule "write LCD"
when
Time cron "0 0/1 * * * ?"
then
sendCommand(LCDprint, line1 + itm_node3_Volt_mqtt.state)
sendCommand(LCDprint, line2 + itm_node3_rssi_mqtt.state)
sendCommand(LCDprint, line3 + itm_node3_rain_mqtt.state)
sendCommand(LCDprint, line4 + itm_node6_light_mqtt.state)
end

CODE 02: here I commented out 3rd and 4th Lines and renamed the 1st and 2nd line to display at 3rd and 4th.
Now I am getting display in 3rd and 4th line. I am not able to display all 4 lines of data together.
Need help to resolve.

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var Timer timer
var String line1 = "2:Battery Volts "
var String line2 = "3:Radio Signal dB "
//var string line3 = "2:Rain Level "
//var string line4 = "3:Radio Signal "


rule "write LCD"
when
Time cron "0 0/1 * * * ?"
then
sendCommand(LCDprint, line1 + itm_node3_Volt_mqtt.state)
sendCommand(LCDprint, line2 + itm_node3_rssi_mqtt.state)
//sendCommand(LCDprint, line3 + itm_node3_rain_mqtt.state)
//sendCommand(LCDprint, line4 + itm_node6_light_mqtt.state)
end

Attachments:

[papa]

It's been a while since I've dealt with LCDs & I don't have any with me where I am for a while.

However I may remember that what looks like 4 lines is actually 2 longer lines. So line 1 wraps around to continue on "line 3"

To test this, you could try printing the Volt & rssi data in one continuous string & see what you get & then pad with spaces as needed.

    Yes, see #7 post by floresta here:

"In general almost all of the LCD modules require that the controller be configured as having two lines of memory. This includes all of the displays with four rows of characters, all of the displays with two rows of characters, and most of the single row (16x1) displays as well. One line of memory deals with rows one and three and the other line deals with rows two and four"