@novicit I was running the beta Domoticz and found the same thing. I rolled back to the stable version and requests worked once again.

I have not updated domoticz for some time, running 3.5877 at present and this is working with requests.

@YFandS said in i2c Lightning Sensor +:

Hello Boots33,

I flashed your sketch in an Arduino pro mini, it is registering but "both" sensors did not show in Domoticz. I had to trigger >them (send a msg with values) after that Domoticz showed them both.

Yes that is a Domoticz thing i think. the node and sensors will show up in the mysensors hardware device after being presented but the sensors will not be seen in the Devices list until they have sent some data. Domoticz will do this with other sensors as well.

The heartbeat is working from the mysensors point of view, confirmation from the Arduino monitor and a led flashing on >the pro mini (I activated the err, tx, rx option) but Domoticz won't register the heartbeat, can you confirm that?

I experienced the same issue, as you said the heartbeat message is shown to be sent in the serial monitor but no update is registered in domoticz. At the time i thought it would be something at the Domoticz end and would be fixed in a future release. I am fairly sure i am using heartbeat correctly. If someone can shed some light on this i would be grateful.

Sorry I have been a bit remiss with this project, I should have mentioned this in a followup post.

I have been meaning to modify the sketch a bit anyway as I am not completely happy with how the data is shown. At the moment the data displays the last strike until new data is available. This means even if there is no lightning around you will still see the most recent strike data.

I would prefer the display to be reset after a period of time until the next storm period. I think I will use this to both clear the display and also be used as a heartbeat. It will only need minor changes to the current heartbeatCheck function.

One last thing I found that even though my sensor is outdoors i get the best results using AS3935_INDOORS in the setup line.

@andredts As you have discovered version 2.1 nodes while booting will not proceed to the loop part of the sketch if the gateway is not found. You can however force them to move on. The line of code you need is...

#define MY_TRANSPORT_WAIT_READY_MS 3000

This code tells the node how long to wait for the uplink to be established before moving on to the rest of the sketch. The number at the end is how long to wait in milliseconds, in this case 3000ms (3 seconds). You can set this to a time of your choosing.

if the node establishes the uplink it will move on without any delay.

The above line is placed near the top of your sketch somewhere before

#include <MySensors.h>

have a look at these for a bit more detail....

MY_TRANSPORT_DONT_CARE_MODE

Synchronising Light switch

@Yago-Casasnovas If you do a search for touch switch you may find a few ideas. This one might be of use.

@moskovskiy82
you could try

if (!initialValueSent) 
  {
    send(msgRelay.set(loadState(1)?RELAY_OFF:RELAY_ON));
    initialValueSent = true;
  }

or perhaps

if (!initialValueSent) 
  {
    send(msgRelay.set(loadState(1)?RELAY_OFF:RELAY_ON), true);
  }

I think isTransportReady() will only test your connection to the gateway not all the way back to the controller.

Requesting the time as @mfalkvidd has said is a good way to check the controller.

@anonymouslemming said in How to build an overridable MySensors relay based device (e.g. lamp with manual switch):

The reason I was considering going via the controller is so that the controller stays in sync. My worry with communicating directly with the node is that then the controller will think that the light is on, when it's off, or vice versa.

You can still notify the controller of the change but use node to node to activate the light. This is usually the simplest way to go. It also has the advantage that even if the controller is not available the light will still switch.

Like i said having the switch connected to the node that controls the light is the most reliable way, but not always the most convenient.

For the initial prototype, it's a lamp that sits in the far corner of the lounge. Control is currently the in-line switch on the lamp cable. I'd like to place the local control switch somewhere near it, if not on the cable, then on the bookcase that the lamp sits on.

The ethernet gateway is about 5m away from this switch and plug socket, with the controller running on a VM on the same ethernet network.

Where is the node that will control the light going to be. Are you fitting it inside the lamp or is it to be external?

You may get some ideas from these posts

AC-DC double solid state relay module

Synchronising Light switch

AC Power controller with node to node remotes

Outdoors Touch Switch light controller

@ago1980 Have a look at this Synchronising Light switch you may be able to get a start from there.

@Euromir The tone function will do that. I have used it in this project to register when the touch buttons are pressed. I have used a small piezo buzzer but i believe a speaker can also be used.

It is very easy to use, just three parameters pinnumber,frequency,duration

So to play a tone on pin 7 at 1200Hz for 60ms you would use

tone(7, 1200, 60);

@anonymouslemming said in How to build an overridable MySensors relay based device (e.g. lamp with manual switch):

In order to get wife approval factor, lamps need to be able to be manually switchable too. She doesn't want to have to get her phone out to turn the lamp on at odd times of day.

A local control is a very good idea for most internal lights.

So far I have 2 ideas for indoor lights, and I'd like to know which one of these seems more sensible.

1. Have a switch attached to the lamp cord (replacing the existing switch) with 2 wires running to the smart plug I'm building. This would change the state of the relay and send a message to OpenHab reflecting this change.
2. Have a completely separate switch, battery powered, attached somewhere near the lamp being controlled. This would include an RF24 radio and act as a control for the lamp.

Option 1 would be cheaper, but have ugly wires running along the lamp wires.

This option will give the most reliable control of the light. If the light is in any way critical to normal day to day use then it is the only option that will give guaranteed control of the light.

Option 2 seems like it would be harder to miniaturize and power for longer periods of time.

This is a good choice if the light needs to be turned on as you enter the room, just like a normal room light requires.
The switch @mfalkvidd has pointed you to is a good example of this.

The down side is you have a lot of places where instability can enter the system. If either of the two nodes loose their connection the light will not work. If your Gateway is down the light will not work. If your controller is down the light may not work. From experience I can tell you the WAF can drop very quickly if a light that is used daily does not work first time every time!

Are there other options that I'm missing ?

There may be other ways to achieve your goal. You could for example use a more novel approach like gesture control or perhaps a knock or clap sensor.

I have used the cheap X10 stick on battery powered wall switches in some areas but these need extra work to interface into the MySensors network.

Now to try and work out how to have a press event on one node trigger the on/off on another node via OpenHAB.

Do you need this to go through your controller? Usually the best way to treat a remote switch is to use direct node to node communication.

Perhaps you can give us a better idea of the physical layout of your setup, this may help us to suggest a more specific solution.