Hello have with the gateway constantly disconnects after a few days and I can only reactivate it by resetting on the gateway.

Have now inserted a separate power supply with a large electrolytic capacitor 5000 µF-let's see....

@hard-shovel said in ESP8266Wifi Gateway won't connect:

MySensors version 2.3.2 and ESP8266 core 2.7.4 works

hello, he runs, after much effort and nerves :-)
The values are a little bit very fluctuating? Probably you can only get away with a very accurate stable voltage of 5.0V.

Unfortunately, it's not that simple. Then it would have worked. What else could have caused this strange behavior?

The MOSFET_outputs are two blank pins. I haven't found anything official about this, except in a post here and a circuit. I supply the voltage converter with VCC and at the bottom of these pins towards the RESET button.

Oh, thank you so much. I had to make some small changes though. Maybe it's the newer Ceech Board version.

 // IO PINS
  pinMode( 13  , OUTPUT ); //unclear why this is so

...


  present(0, S_MULTIMETER);
  present(0, S_CUSTOM);
...

digitalWrite( POWER , HIGH );

...

digitalWrite( POWER , LOW );

Hi, I'm working with Ceech-Board for a pool sensor. I'm rewriting the code from V1.5 to 2.x. I encountered a problem with DIGITALWRITE which I can't explain.

Only if I set PINMODE unequal to the PIN for DIGITALWRITE, this output works.

void setup() {
  pinMode(5, OUTPUT); // Setzt den Digitalpin 13 als Outputpin
}

void loop() {
  digitalWrite(4, HIGH); // Setzt den Digitalpin 13 auf HIGH = "Ein"
  delay(1000);            // Wartet eine Sekunde
  digitalWrite(4, LOW);  // Setzt den Digitalpin 13 auf LOW = "Aus"
  delay(1000);            // Wartet eine Sekunde
}

It worked with pin 3, 5 and 13 e.g.

On the board the PIN D4 is followed by a MOSFET for switching. This worked once, once again not. No I seem to have found the problem, but what is the cause?

I'm getting low readings. The voltage at the sensor was OK. So it had to be the calculation. In my opinion the conversion of the 1023 values into a voltage is missing which can then be calculated further.

uint16_t   uv = analogRead(UV_SENSOR_ANALOG_PIN);// Get UV value
    uv = (uv* (5 / 1023.0))*1000; 
    if (uv>1170) {
        uv=1170;
    }

Thank you very much :smiley:

https://smarthome.gleisnetze.de/kategorieren/14-it/46-modul-5-sensoren-fuer-smarthome-arduino-fhem-mysensors

API 2.0

Sensors:
HC-SR501 (Motion)
DHT-22 (Temperature/Humidity)
MQ135 (Airquality)
MH-Z19/14 (CO2) --> Coming soon

https://smarthome.gleisnetze.de/j/kategorieren/14-it/44-dallas-ds18b20-temperaturmessung-mysensors-api-2-0-und-fhem

@paqor
Probably one should not speak of a sensor CO2 value as well as responding to many other particles at the MQ135. The most accurate CO2 measurement we certainly be possible only with a MH-Z14. I now have to buy me a part and will then calibrate the MQ135 so. With the MQ135 can z. B. only say something about the air quality in relation to the outside air. It is rather a relative value.

Here the comparison of MH-14T (yellow) and MQ135 (red). One sees the calibration and as yet are both curves to each other.
[https://smarthome.gleisnetze.de/38-mhz-14-erste-erfahrungen-mit-dem-co2-sensor-fuer-mysensors-arduino-fhem]

Wahrscheinlich sollte man beim MQ135 nicht von einem CO2 Wert sprechen da der Sensor auch auf viele andere Partikel reagiert. Die genaueste CO2 Messung wir sicher nur mit einem MH-Z14 möglich sein. Ich habe mir jetzt so ein Teil bestellt und werde dann den MQ135 damit kalibrieren. Mit dem MQ135 lässt sich z. B. nur etwas zur Luftgüte im Verhältnis zur Außenluft sagen. Es ist also eher ein relativer Wert.

@TheoL said:

@paqor That's great. I looked at the Sketch you posted on your site and noticed you're still using a delay. Which as short as it may be can cause messages to be missed.

void loop(){
//-----------------------------------------------------------------------------
//TEMP_FEUCHTE 
delay(dht.getMinimumSamplingPeriod());

My advice is to do this with a wait as well.

void loop(){
//-----------------------------------------------------------------------------
//TEMP_FEUCHTE 
wait(dht.getMinimumSamplingPeriod()); // Changed ByTheo

That way you don't block incoming messages. Generally, if you want your sketch to wait use a wait.

genial, works perfectly....