Release 2.2 Gateway

[computourist]

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

In version 2.2 of the gateway the handling of binary inputs is made compatible to Openhab.
On every state transition a message is generated; the message block contains "ON" or "OFF" depending on the input state.

In Openhab you have to declare a "contact" item:


Contact window "Status [%s]" {mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev40:state:OPEN:ON],<[mosquitto:home/rfm_gw/nb/node02/dev40:state:CLOSED:OFF]"}


and a frame in the designmap to show the state of the input:


Frame label="Contacts" {
Text item=window
}

Note that end nodes with binary input (DHT node and LCD node) have been updated to reflect these changes.

etrombly has written a relay end node, that has been merged into the repository. He has provided a device class that should make it easier to develop new end nodes.

- Computourist

[tavalin]

Hi Computourist

Good to see your progress! I had forked your repository to make some improvements regarding developing/adding new devices to end nodes but it seems etrombly has beat me to it!

I am in the process of pulling the changes and then I'll retrofit the debug improvements I'd made back.

[ubergeekseven]

So, looking at the wiring diagrams you have, the gateway w5100 does not have any ground connected. Is this working for you?

[computourist]

Yeah, it's all wireless......


Thanx, I changed the drawing...

Mar 18, 2015 12:43:50 GMT ubergeekseven said:

So, looking at the wiring diagrams you have, the gateway w5100 does not have any ground connected. Is this working for you?

[ubergeekseven]

For a split second, I thought you were serious. I'm working on recreating your setup from scratch. I have a big box filled with the components needed to build arduino compatible boards, so I'm trying to make one board that will be able to contain all sensors and outputs as well as jumpers to select the Ethernet device on the same board. I was comparing yours to mine and saw the ground.
It will probably keep people from saying it in the future

[computourist]

Not sure I understand you correctly. For a sensor network you need only one single gateway with an ethernet interface. No need for jumpers, sensors, output, etc on the gateway.
I can imagine such a uniform board for the sensor end node, but then there's no ethernet on the end node...

Mar 19, 2015 14:54:31 GMT ubergeekseven said:

For a split second, I thought you were serious. I'm working on recreating your setup from scratch. I have a big box filled with the components needed to build arduino compatible boards, so I'm trying to make one board that will be able to contain all sensors and outputs as well as jumpers to select the Ethernet device on the same board. I was comparing yours to mine and saw the ground.
It will probably keep people from saying it in the future

[tp]

Hi, I have a problem regarding the radio and ethernet module.
First of all I tried your setup with a Pro Mini (as in the images) and also with an Uno R3 and level converter so that the RFM69 won't get damaged. Both Arduinos are "compatbile" China versions. I tried two China ethernet shields and I also got the genuine ethernet shield.

Which Arduino IDE are you using? Currently I'm using 1.65 and also tried 1.60. I changed two lines in the w5100.h but it won't work. If I unplug the RFM69 power it instantly connects to the MQTT broker, so it's probably due to the SPI problem.

Please tell me which IDE version you are using and if I should try some different ethernet or SPI files. Thank you very much!

edit: I ommitted the mqtt link and radio led, left the code unchanged and just didn't connect leds - I think thats okay..

[computourist]

Hi TP,

I'm using an old version of Arduino IDE (1.05), never bothered to upgrade. But that should not cause any problems.

The SPI conflict only occurs when the RFM module receives a radio packet. The RFM will generate an interrupt request and will access the SPI bus. By disabling responses to the interrupt request whilst the ethernet module is using the SPI bus this problem is solved.

This means the connection to the MQTT broker should be established and remain connected until a conflict occurs. If you have no end node transmitting, no packets are received and the connection with the MQTT-broker should not be affected.

I think you have a different problem.
What is the serial output with/without the RFM connected ? Have you checked your supply voltages with/without the RFM ?

Leaving out the LED's is no problem.

[gandalph]

tp did you connect the RFM69 to pin 8 instead of 10?

[computourist]

I suspect TP is having problems with interfacing to the RFM module.
He writes he is using level converters to interface between 5 Volts and 3.3 Volts systems.

In case of the gateway, the ISP bus MUST be able to float, in order to allow RFM or ethernet to seize the bus.
Normal level converters do not allow this, and do not free the SPI bus. You would need tri-state for that (ON,OFF,FLOAT).

The most simple approach is really to use only 3.3 Volts.