Posts made by rejoe2

@mick Thanks for coming back to this topic, the stuff arrived already some weeks ago, but unfortunately I was busy with other parts, amongst them btw. a modification of the MySensors plugin for FHEM to get probems shown more easily. So finally some soldering work was on my list yesterday. So today there's the option to at least give some first impressions on that:

• Network is @57600 for the use of the TJA1050 modules.
• Soldered some adopter boards for direct replacement of the modified LC-Tech MAX487 modules, (crossed RX/TX as usual, there's no DE/RE, later also desoldered the 120 Ohm resistor)
• plugged it in Node_2's socket, and

WOW: It worked!

Tried a second one on the same node (module without the 121R): Also worked

So I continued and tried to teplace the transceiver at Node_3 with the tested (now resistorless) one:

NO LUCK!

Continued with the last transceiver in line holding the pullup/dow resistors: Also no luck

So I decided to stop at that point to see how Node_2 will perform over night and meditate on the question why the behaviour on the other two nodes is different. Kept Node_1 and Node_4 not connected to the bus, so starting the experiment just with 3 nodes and the GW online.

This mornings's findings:

• (Node_2 hat at least once spontanously rebooted, but still was sending in data. I's rate this as some kind of partly success, but obviously the node needs to be reviewed, there most likely exists a problem not related to RS485.)
• (Node_5 was offline for whatever reason, no issues - as always - on Node_3)
• These transceivers can be used for MySensors@RS485
• They can be used in a mixed network together with normal transceivers
• BUT: (hypothesis) They may not be used in combination with altSoftSerial; Node_2 is HW-Serial, the other two still use software, so for them DE/RE might be essential (ISR?)

Additional remarks: I tried also a different power source for the 12V a couple of weeks ago - no difference (MAX487-only bus)
The GW was online during all of the time, it's uptime is 7 days by now (also SW-serial).

So I'll have to do some more testing on some of the topics and perhaps also build some more test nodes to avoid touching my "normal" bus too often - this seems to also cause additional trouble...

I'll come back when I know more, but again, this will take some time.

@bakcsa Thanks for this great summary!

@sergio-rius Sorry for the somehow misleading referer: Meant was : "Me not beeing ..."

@soloam OK, so in the end this seems to be a problem related to that particular controller software. Imo it would be better to address this issue by enhancing the controller software towards a more constant handling of added infos from user side like renaming devices rather than using the limited space on the mcu to store info not needed by other controllers.

@sergio-rius You know about the MySenors roadmap? It's open visible to everybody here: https://github.com/mysensors/MySensors/projects. Aint't that the sort of "list" you were thinking of?

Not being part of the dev community, but most likely there are no "hidden side projects", so in case you have additional ideas for the roadmap, feel free to open an issue on github .

But most likely we are far OT by now here.

@qobouky
Interesting approach, I have some ideas to also go this route (just as a central scene controller), but didn't find the time yet to get that done (and some other challanging tasks with higher priority).

So some of my findings wrt. using displays with MySensors:
Sharing SPI is possible, see e.g. the Dollhouse TV example. I also did some poc work wrt. that, code is here with two digital SPI resistors parallel to the nRF - works, just requires 2 additional pins for CS and some initialisation in before().

But as especially using graphics modes might need more power and memory than a ATMega328 can provide, the scene controler uses an ATMega 2650.
If you want to miniaturize things, you may have a look at other mcus like STM32F103 or NRF52. One of my next projects will most likely "require" to use the STM32 (also MySensors, but - most likely at least in the first version - not with a display).

@alowhum
Some more personal remarks (hard to do in english, to be honest):

Reading your postings wrt. to the DS18B20 things and your enhancement proposals, I can somehow understand about your frustration. (The DS18B20 and BME280 I also use, so this is a part I can follow to some extend, other than a lot of other hardware you mentioned). I also suffered from changes in the libs that made it not to easy to get things going (routines from "the outer world" becoming private and so on). And some of the comments on your code in the mentioned thread are rather hard to understand or interpret.
As I also did one pull request in the past, I also know how high one's frustration tolerance has to be just to get through the necessary organisational process (including copyright questions and so on).

But: this is necessary stuff to go through... And the devs here are really doing a great job in quality assurance - at least imo.. But to be honest: It also took me quite a lot of time to find out, how difficult it in fact is to choose the right compromise between a lot of aspects.

Just one example: Your last proposal wrt. to temperature was to use BME280 as a future standard. Did you ever use more than 2 temp sensors on one node? Most likely not, as this is more or less only possible using the 1wire protocoll (I have around 25 of them on 3 nodes using 7 Pins as data lines).
And BME280: Try to compile the last version of the lib for ATMega328: It's broken... And the lib consumes way more memory (ok, to be honest: most likely most is for doing forecast calculations).
So please keep two things in mind:

• The two of us just see a small part of the world and are just about to start understanding how things really fit together. So going just one step after the next is best way to do. Don't be to eager, good ideas will find their way in the MySensors or Arduino code base.
• There are a lot of forums around, but only a few have the spirit you find here: If you ask your questions, you will most likely get a friendly answer that could bring your project forward!

So a big thank you to all the devs and mods around here! Great job!

Two remarks:
Both of my serial 2.2-GW's stay at "startup complete" and are working as expected (seems to have changed somewhen in the development of 2.0). Trying to set them to "connect" causes a reboot ending again in "startup complete".
So this is not really a fault, just let them state "startup complete" and don't worry too much about that.

If the Arduino really is spontaneously rebooting, this could also be due to a fault in the Arduino design (Test PION floating). But as you described the "problem" shows up also with the adapter/pro mini version, this seems not to be the case here.

Perhaps using a different microcontroller could also be an option?
I'm personally not to deep in these things, so this might be completely wrong, but at first sight I'd try to get this working with a STM32F1 board. Seems that using them in conjunction with direct access to the ADC might speed up things, see http://wiki.stm32duino.com/index.php?title=API#Reading_from_.26_Writing_to_pins as a short reference.
And using MySensors with STM32F1 seems to be used by several users here.

You seem to send the temp messages under a different ChildID than it is presented:
presentation takes "1", send uses "0". You have to allign that, e.g. by using

send(msg.setSensor(i+CHILD_ID_TEMP).set(temperature,1));

But as long as there's just one DS18B20 doing that dynamically doesn't really make sense. Using the defined message structure (MyMessage msgTemp...) could make things more transparent.

Also there's no sending command for voltage. So why do you expect the controller to receive also voltage?

Didn't test this, but using a vibration sensor (modules are available under the namee "SW-420 Vibration Tilt Sensor Alarm" at big market places) might also be an option. Should provide digital and/or analog signals.

Best success with your project!

@gabriele-cirillo said in More relay and push botton:

ps: i deleted what??!?!?

Your code was to some extend very close to @korttoma's. So I thougt you started with a "cleaner" version ot this base and let out some parts - especially things related to

#include <Bounce2.h>

To me, these things are also quite close to magic, don't worry .
I don't know, what is going on at bootup, but my assumption wold be the PINs are somehow floating, as you didn't do some kind of initialisation in setup() or comparable.

Add. remark:
You also deleted the original debouncing function - that's possible, but as you seem to be quite good in adopting things (imo you made a big step forward). So you may review your code once more wrt that; could be the debouncer-function does a little more than just wait some time .

OK, this is a different topic: as long as there is no uplink to the controller, your sketch will never enter loop() and so on.
Sounds like there is no radio module attached? Please see hints in troubleshooting, especially: log parser.
As a workaround you may get node starting without radio by using

#define MY_TRANSPORT_WAIT_READY_MS 3000

But some remark wrt applying fixes like that: It's kind of frustrating to discuss basic things when beeing asked for help on really advanced features. Imo, you might get some more basic examples to work first before starting projects like the one here.

Just my2ct...

@gabriele-cirillo Can you please be a little more specific: What exactly is not working? What's the serial output?
I have to admit, I never directly used @korttoma's sketch directly, but used the principles he applied to make own things happen. So if you want to dig into this a little more in depth, you may have a look at these here and here (the later not yet finisched, but button+relay-wise working).

@gabriele-cirillo Sorry, but the one you posted may be the sketch of the first post in the linked thread, but my link (at least on my computer here ) leads to a very different sketch using arrays for assinging PINs and buttons. See post #33 by @korttoma in the linked thread.

@gabriele-cirillo Can you please reformat your post using code tags (</>-button above the editing field)?
Wrt. to your sketch: Why do you use different childIDs in the receiving part than in the header?
Did you have a look at the sketch in the above link? You will have to learn a little, how to use arrays, so please first try to understand how it works. I agree, this is not a very simple example, but as you asked for one...
Don't really expect me (or somebody else) to deliever completed code - in the end it's up to you to connect your buttons and SSR's to the arduino, so you should know, what you are doing .

You may have a look at this example here to avoid redundancies in your code: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33#

@dirkc said in Multiple Relays + Motion sketch, fully customizable, optional timer, manual override:

@ostoja said in Multiple Relays + Motion sketch, fully customizable, optional timer, manual override:

// Present all sensors to controller
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
     present(i, S_TEMP);
  }

  // Register all sensors to gw (they will be created as child devices)
  for (int sensor = 1; sensor <= NUMBER_OF_RELAYS; sensor++) {
    present(sensor, S_BINARY, "Relay", ack);
  }

With this two "for" loops you set present(n) multiple times. in the first for() you start with 0 until MAX_ATTACHED_DS18B20-1, in the second for() you start with 1 until NUMBER_OF_RELAYS-1
I have not checked the internal code of this method, but I would think that you should better user a different range in the second for() loop starting at least with MAX_ATTACHED_DS18B20+1.

Additional remarks:
For the relays better start with 1.
Shift the Temp values to higer range (use e.g. a variable like FRIST_DS_SENSOR_ID).
Check, if the receive()-part and the ID you get really fits together with the relay you want to switch.
Don't try to read the temperature values every few parts of a second. Use a millis()-routine.

Please search the forum, there have to be at least 2 threads with exactly the same problems in which I posted how to solve this. You are "trying to reinvent the wheel".

@ostoja Please add your code. Most likely you just transfered the DS18x20-Code into the relay sketch including the sleep() at the end of the loop().
If you did it that way: This had been discussed here several times, you have to change the code into a so-called non-bocking loop().

Just in case the Arduino you use for the GW is also equiped with an FTDI USB-serial chip:
Check wheter the test pin is correctly set to GND. The TEST-Pin is # 26 on the FTDI-IC and can be soldered together with neighbouring AGND (PIN 25).
Some background info: your controller resets the GW when connection to serial. If your board is suffering from this issue, TESTPIN bay be floating, and this finally leads to an endless reboot.