Posts made by kted

@electrik Going through the documentation of the Orangepi, I found out that the config should be

--my-rfm69-irq-pin=71 --my-rfm69-cs-pin=233

but still no dice. I also get an error:

Mar 28 14:11:14 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=0,VER=2.4.0-alpha
Mar 28 14:11:14 DEBUG TSF:LRT:OK
Mar 28 14:11:14 DEBUG TSM:INIT
Mar 28 14:11:14 DEBUG TSF:WUR:MS=0
Mar 28 14:11:14 DEBUG TSM:INIT:TSP OK
Mar 28 14:11:14 DEBUG TSM:INIT:GW MODE
Mar 28 14:11:14 ERROR Interrupt handler error: Bad file descriptor
Mar 28 14:11:14 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Mar 28 14:11:14 DEBUG MCO:REG:NOT NEEDED
Mar 28 14:11:14 DEBUG Listening for connections on ▒]o:5003
Mar 28 14:11:14 DEBUG MCO:BGN:STP
Mar 28 14:11:14 DEBUG MCO:BGN:INIT OK,TSP=1
Mar 28 14:11:14 DEBUG TSM:READY:NWD REQ
Mar 28 14:11:16 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

The IRQ pin is connected alright, the RFM69 module works perfectly on a RaspberryPi or an OrangePi Zero.
It just refuses to receive when used on the OrangePi Zero 2 Something with pin assignements or SPI...
It is a a new SOC, so maybe I should wait for someone with more expertise than me to work it out...

Did anyone manage to make it work on an Orangepi Zero 2?
It compiles (after some tweaks) on armbian, it starts OK, trasport seems OK, it can transmit, but not receive.
Out of the box, it comes with

ls -l /dev/spidev*
/dev/spidev0.0
/dev/spidev1.1

My config:

./configure --spi-spidev-device=/dev/spidev1.1 --my-transport=rfm69 --my-rfm69-irq-pin=2 --my-rfm69-cs-pin=13 --my-rfm69-frequency=915 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003

The output is

Mar 23 18:17:18 INFO  Starting gateway...
Mar 23 18:17:18 INFO  Protocol version - 2.3.2
Mar 23 18:17:18 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=255,VER=2.3.2
Mar 23 18:17:18 DEBUG TSF:LRT:OK
Mar 23 18:17:18 DEBUG TSM:INIT
Mar 23 18:17:18 DEBUG TSF:WUR:MS=0
Mar 23 18:17:18 DEBUG TSM:INIT:TSP OK
Mar 23 18:17:18 DEBUG TSM:INIT:GW MODE
Mar 23 18:17:18 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Mar 23 18:17:18 DEBUG MCO:REG:NOT NEEDED
Mar 23 18:17:18 DEBUG Listening for connections on P▒E:5003
Mar 23 18:17:18 DEBUG MCO:BGN:STP
Mar 23 18:17:18 DEBUG MCO:BGN:INIT OK,TSP=1
Mar 23 18:17:18 DEBUG TSM:READY:NWD REQ
Mar 23 18:17:21 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

I tried also with the development branch (fewer tweaks) but with the same results.
Any help would be appreciated

It's a known bug (or feature) of the Rspberry Gateway + RFM69. RSSI values are wrong, so you cannot use ATC
What I do, is i use

#define MY_RFM69_ATC_MODE_DISABLED
#define MY_RFM69_TX_POWER_DBM 0

and set the TX_POWER_DBM to the lowest value I can, by trial & error...

Have you guys considered using a US-100 ultrasonic sensor instead?
It can be used in the usual "ping" method, or in serial mode, in which case you can also get a reading from the built-in temperature sensor, and the distance measurement is automatically temperature compensated.
And it also works reliably at 3V.
I was using it for a year without problems in an diesel tank, and made the mistake to replace it with a TOF sensor. Now I'm back to the old reliable US-100.

It's even simpler than that. Just add a line as the one below:

#define MY_SIGNING_SIMPLE_PASSWD "mypassword"

@gohan I meant multiple gateways on the same raspberry.
Right now, I have an NRF24L01 gateway, Domoticz, pi-hole, and a VPN server running, with 2 more gateways connected, one local and one remote RFM69 on ESP8266.
It would be nice if I could combine the two local gateways, the RFM and the NRF on the same Raspberry's GPIO...

@gohan Nice. I was thinking to do that same at some time, but I wasn't sure if the Raspberry could handle the load, since I also run domoticz on it, along with pi-hole.
How many devices do you have on each gateway?

@rolo6442u From what the node itself reports from transportGetSignalReport(SR_TX_POWER_PERCENT). It starts from say 50%, and after a coule of transmissions it goes up to 100%, when the nodes are 1m apart. When using a stand alone ESP8266 gateway, it drops to 0%.
I'll have the nodes ready in a couple of hours, after I come home from work...

@rolo6442u I built an Raspberry gateway using an RFM69 radio, to replace one built around a NodeMCU.
All nodes are transmit only, and using the latest stable API.
I noticed that all sensors were using max TX power after the first couple of transmissions, although they were respecting the ATC setting before, and were using minimum power most of the time.
Now I am concerned about battery life, so I switched back to the NodeMCU gateway, waiting for a fix.
I'll put together a temporary net, with a RPi0 gateway and a single node later, to show some real data, if you need any more information.

Has the issue with RFM automatic transmission control been addressed?

Any news from the developers on this issue?

@electrik I didn't modify the whole network, just two nodes as a receiver and transmitter. I'm waiting for the SDR-RTL first...

@electrik They work fine if I just change the frequency definition from RFM69_868MHZ to RFM69_915MHZ, but I don't know if the frequency actually changes. Currently I'm waiting for an RTL-SDR dongle to arrive, so I can make some tests to be sure...

Anyone here with experience on using RFM69HW radios marked or 868MHz tune via software to operate on 915MHz?
I ordered several of them to replace some long-distance NRF24L01 sensors that I had problems with, and it seems they interfere with my wireless alarm system, which constantly complains about possible interference and starts blaring at odd times...
I know they work, but I don't know if it is advisable to operate at a different frequency, either for transmitter life expentacy, or spurious harmonics and what not.
Thanks in advance.

@mfalkvidd sorry, I was talking about the US-100 distance sensor. Jumped the gun here.

@dbemowsk I have one sensor (oil tank level) running on an Arduino pro mini, with LEDs & regulator removed on 2 AA batteries for 2 months now.
I use pins 3 & 4 of for power and ground, and the hardware serial to communicate with the sensors. I take a reading every hour. No significant voltage drop so far, the battery level has only dropped by 3%.
I do get occasional spikes though, so when I get to it, I'll modify the sketch to take 3 readings and send the median.

@user2684 Actually, you are right. Thank you.
But shouldn't the compiler throw an error?

Now to the hard part: How to send the actual command from Domoticz, for example to change the sleep duration...

I just started using NodeManager, mainly for the ability to send settings to the node.
I started with a plain analog (Voltage) sensor, and it works just fine. But I cannot make a DS18B20 sensor to send any temperature data. It registers on the gateway, and that's it.
I have enabled the DS18B20 module in the config.h.
This is the code in the sketch:

  /*
   * Register below your sensors
  */
  nodeManager.setSleepSeconds(10);
  nodeManager.setReportIntervalSeconds(10);
  int temp = nodeManager.registerSensor(SENSOR_DS18B20);
   /*
   * Register above your sensors
  */

Am I missing something?

@mfalkvidd Haven't tried that.
I'll give it a chance just in case.

OK, problem solved.
First of all, I stopped using SoftSerial, and I am now using the regular serial port.
I can't debug the node any more, but it is working.
And the drain dropped to 1.9 mA.
This is the US100 idle current, so that was also a problem.
So I chose to power the sensor from pins 3 & 4, as VCC and GND, since just using pin 3 and GND kept the drain to 1.9mA
I turn pin 3 to output high and pin4 to output low, wait 5 seconds to let the sensor stabilize, since it gave erratic readings with anything less, take the measurement, and turn pins 3 & 4 to inputs, so there is no drain.
Seems to work so far, after a whole day of taking readings every minute, I am down by 10mV. I intend to take readings every 2 hours in normal operation, so I figure the batteries will last for about a year.
I am writing this from my phone, so I cannot post the source if anyone is interested, but let me know...

I've built an oil tank level sensor, using the US100 ultrasonic sensor. The sensor, when communicating via serial protocol, has the capability to compensate for temperature variations, and is a lot more accurate than the traditional "ping" method.
My problem is the current drain.
When I enable the software serial port, the current drain during sleep goes from a few nA to 2mA, and the 2 AA batteries powering the node, only last for a couple of weeks.
I take measurements only every 3 hours, but I have the battery reporting it's level every 30 minutes, and it is dropping like rock.
Any suggestions for implementing a serial port for a battery powered sensor? (Pro mini @3.3V/8MHz, with NRF24L01+, powered by 2 AA batteries).

Have been using this for more than a year, without problems
http://s.aliexpress.com/iAJRFfY3

I was using a plain 5V solar cell at first, but later I used a rainproof solar LED light as a housing, after removing everything except the solar cell.
http://s.aliexpress.com/MR7RjYb2

The node has an NRF24L01 PA version (with the antenna), and communicates with the GW 6 stories below, sending the solar water heater temperature every minute.

@SubodhChettri Since you have removed the regulator, you should power the mini with 3.3V.
This is provided either by the jmodule's LDO which is capable to power the NRF, or directly by the battery (2xAA).
If you are using batteries, you dont need the LDO, so you bridge the Vin& Vout, and the 3.3V that feed the Mini go also to to the NRF.

@Nca78 So, the capacitor is on the other side of the board, it just doesn't show in the photos. No problem with the SMD components, they are large enough if you are a bit careful.
You are wasting precious time writing in the forums. Get back to work!

What about the NRF decoupling capacitor? Is there a provision for it?
In the previous version there were holes for one. Is it SMD now?
Any other details on the new features? My fingers are itching for an order....

Duh!
Just realized that the node is sleeping while waiting for the message!
There are no debug messages while waiting, the node just sleeps.
What threw me off, was that the time and date are received OK, but that was at the beginning of the first loop, while the node was awake.
I'll try the request() function ASAP.
Thanks.

MySensors 2.0, and the node is just an Arduino Pro mini with a NRF24 and an OLED display. No other function is enabled on it.
I use it to display the solar water heater temperature next to the switch that powers the heater when solar power cannot heat the water enough.
The sending node is several floors away, and communicates successfully with the gateway, using NRF2401 PA modules.

In the past I was able to succesfully send messages from node to node, and they were shown on the display, but now the distance is too great, and the receiving node has no external antenna.

Thanks for the suggestion. I will upgrade the controller and this node to 2.1, and see what happens.
Will there be a problem if the other nodes (about 8 of them) remain at the 2.0 version for a while, until I upgrade all of them?

Hi.
I am trying (without success) to send text from the controller to a node with a OLED display.
The node registers successfully with the controller, gets an IDx of 8, and is enablad
I am trying to send a text value (a temperature from another node actually) to be displayed, using JSON
An example command is http://192.168.1.13:8080/json.htm?type=command&param=udevice&idx=8&nvalue=0&svalue=hello
The text shows in the device list in domoticz, but the receive() function never fires.

This is my receive() function

void receive(const MyMessage &message) {
  Serial.print("Sensor: "); Serial.print(message.sensor); Serial.print(", Message: "); Serial.println(message.getString()); 
  if (message.type == V_TEXT) { 
    if (message.sensor == OLED_CHILD) {
      OLEDtemp = message.getString();
    }
  }
}

I also tried passing the value to the node via a LUA script, without results.
What am I doing wrong?

How about a version with the SDA & SCL pins also routed to the header?
Sensors like the Si7021 are using the I2C interface