[RELEASE] OmniThing v0.8.2 - ESP8266/ESP32/RaspberryPi/Linux/Windows Web-based Configuration Tool

So, I spent 4 hours tonight trying repeatedly to get this to work and I think I’m just not smart enough. All this bool this and offset that and subscriptions and triggers… it is just too darn complicated for someone who’s not a programmer. And i know more than the average Joe. Looks like a really promising project but I just can’t figure it out. A few example json files might be a big help. That way we at least know if we’re starting to get close to the right direction.

I understand. There are multiple layers involved in adding a device, and that can make it complicated. I intend to add some examples and perhaps some beginner tutorials in the near future.

1 Like

Thanks! :slight_smile:

I FINALLY GOT IT! I dunno how it came to me but I was working through my Hubitat transfer and it dawned on me. You don’t actually need to define the Trigger and Subscription in the device config. I left those out and the rest just worked. I kept getting caught up on need both of those and it tally was confusing the hell out of me. Don’t know why it didn’t occur to me soon. Thank you for humoring my endless tirade of questions.

2 Likes

Hello all,
Well we have a baby on the way and being all excited about this my brain is on overdrive :slight_smile:
So i am thinking about constructing a sensor box (obviously it is NOT going to be a main, life depending entity gadget) but more as a back up novelty type of actual approved gadgetry such as baby sound, video and motion monitors sold at mom approved baby stores etc.

What i want to do is a Raspberry Pi that will have connected to it a camera for monitoring in distance (solved this part already), a speaker for lullabies (solved as well), relays to control the switches for the automatic baby rocker (solved as well … Alexa turn on Baby Rocker)… but i was also thinking about incorporating some sensors, 5 to be exact to the same Rpi;

  1. Sound sensor
  2. Soil sensor
  3. Vibration sensor
  4. Motion sensor
  5. Temperature sensor

I don’t want to do anything fancy things with these sensors (most likely a ST multipurpose sensor will take care of the last 2) other than when they are triggered i want SmartThings to buzz a signal and change a light to different colors depending on which sensor was triggered.

i was doing some research and that is how i landed on this thread…will this OmniThing be able to help me and how??

Any help will be greatly appreciated

Denis

Hi Denis,

OmniThing can definitely do the last two sensors with little trouble. As for the first three it would depend on what sensors you’re planning on using. Anything that works by toggling a digital gpio pin to signal a state change should work pretty easily. If you’re planning on using something that outputs an analog voltage (I know many soil sensors do), it will be trickier due to the raspberry pi’s lack of analog input pins.

Do you know which specific sensors you’re wanting to use?

Hello Daniel,
I was just about to write you on our old conversation we had about a year ago. :slight_smile:

The sensors are the simplest out there pure digital high /low when it moves change the GPIO pin value to high, when it cries change it to high, same with soil if i ever use it :smile: if it poops take it to high …(or low)
Here are the sensors i am interested on (from from top left going right and under) the slot position on the first illustrating picture as follows #2, #7, #8, #14, #16


pretty simple stuff, more to say that i did it rather than utilitarian, if you, or my family for that matter are to lough LOL .
I wanted to use a Raspberry pi just so i can also control some relays and utilize a web cam in the same set up

Please guide me as to how to tackle this
Again Thank you, thank you
Denis from Dallas, TX

Hi Denis,

Sorry for the delayed reply.

Those sensors should be very easy to implement with OmniThing if they just toggle a gpio. I’ve been meaning to write up some tutorials for using OmniThing, and your project seems like a good example to use.

I’ll try to throw something together this weekend or coming week.

@leinax Thank you buddy looking forward to it let me know how i can help i am eager to get this going
Denis

Ok so i have my new Raspberry Pi set up i am hooking up the sensors one by one and i have downloaded and installed Omnithing on the Rpi.
I can access the web interface for the configuration tool from withing the raspberry pi.

Right after this i am going to set up the ST IDE part for app control but right after this i am going to need some help as to what to do next cause i have no idea.

the sensors are again

  1. sound sensor
  2. motion sensor
  3. vibration sensor
  4. soil sensor
  5. temperature/humidity sensor
  6. 2 X relays

All sensors are simple gpio toggling form the kit above and the relays are simple on/off right after finishing hooking them up on the breadboard i will give you the gpio numbers if you need them and hopefully you will have some time to help me out :slight_smile:

thank you again
Denis

Hi Denis,

Yeah the GPIO numbers would be great. I can set up a baseline json configuration you can import into the web interface.

Noobish question…I may just be oblivious to the answer if it’s been mentioned.

I have an ESP8266 with a relay and an open/close sensor connected to the GPIO pins. I used Konnected.io to set up the relay and sensor as independent ST devices. I tried using webcore to turn the relay on and then turn it off when the sensor closes. However, the communication lag is unacceptable for my intended use.

Does Omnithing make it possible/easy to configure and perform this logic between the relay and sensor locally on the ESP8266?

Yes. OmniThing has a limited event/subscription system. You can set a Switch device to power on/off based on a ContactSensor device’s events. That processing takes place on the esp8266 itself, so there’d be very little delay.

2 Likes

I just switched over to OmniThing from some custom python / REST code I was using for a few DHT22 temperature/humidity sensors. I’m loving the flexibility it gives, but I’m having a strange issue that I hope someone can help me diagnose.

I have two RPi Zeros, each setup to use a DHT22 for temperature/humidity measurements. They are both using an identical config.json file (only differences being the monitored pin and the measurement names) and are reporting into the hub properly. Both are only very intermittently reading values from the DHT22, and almost always reporting an error and sending the last known good value.

My custom python code (which uses the Adafruit_DHT pip package) still works fine on both RPIs and consistently returns a temperature and humidity reading from the DHT22, so I don’t think the sensors are bad. I have commented my old code out in cron, so it’s not in contention with OmniThing.

Here’s a typical log from each interval:

Poll triggered for RelativeHumidityMeasurement generator_humidity
DigitalOutputPinRaspberryPi: pin=6 val=0
ERROR: error reading temp/humidity (-2)
ERROR: Failed to get float=humidity from DHT22
{“name”: “generator_humidity”, “type”: “RelativeHumidityMeasurement”, “humidity”: “27.600000”}

Sending json: {“updates”: [{“name”: “generator_humidity”, “type”: “RelativeHumidityMeasurement”, “humidity”: “27.600000”}]}
Return value: 202
Poll triggered for TemperatureMeasurement generator_temperature
{“name”: “generator_temperature”, “type”: “TemperatureMeasurement”, “temperature”: “18.799999”}

Sending json: {“updates”: [{“name”: “generator_temperature”, “type”: “TemperatureMeasurement”, “temperature”: “18.799999”}]}
Return value: 202

A few more details that might be useful:

  • both are RPI Zeros - one is a “Raspberry Pi Zero W Rev 1.1” and the other is a “Raspberry Pi Zero Rev 1.3”
  • both have soldered headers (by me, and I suck, but I think I did pretty well on that)
  • one is a new stretch install, the other is a jessie->stretch (seemingly successful) upgrade
  • both are many miles away (and one is in a sealed enclosure that can’t be moved), so physical inspection isn’t possible

Any help in diagnosing this would be much appreciated!

Dave

I have seen the same problem with a Pi Zero W and DHT22 sensors. So, I think the problem may be within OmniThing’s choice of software to communicate with the DHT Temp/Humidity sensors. Hopefully @leinax can look into this for us! :wink:

Great, thanks for the confirmation. Here’s config.json if it’s helpful:

{
“NetworkReceiver”: {
“type”: “NetworkReceiverHttpLib”,
“port”: 8090
},
“NetworkSender”: {
“type”: “NetworkSenderHttpLib”,
“ip”: “192.168.21.11”,
“port”: 39500
},
“CompositePeriphs”: [
{
“type”: “DhtReader”,
“name”: “DHT22”,
“pin”: 4,
“pullup”: false,
“dht11”: false
}
],
“Devices”: [
{
“triggers”: [
{
“interval”: 150000,
“offset”: 0,
“command”: “poll”
}
],
“subscriptions”: ,
“type”: “RelativeHumidityMeasurement”,
“name”: “timelapse_humidity”,
“input”: {
“type”: “InputFloatRef”,
“compositeName”: “DHT22”,
“paramName”: “humidity”
}
},
{
“triggers”: [
{
“interval”: 150000,
“offset”: 1000,
“command”: “poll”
}
],
“subscriptions”: ,
“type”: “TemperatureMeasurement”,
“name”: “timelapse_temperature”,
“input”: {
“type”: “InputFloatRef”,
“compositeName”: “DHT22”,
“paramName”: “temperature”
}
}
]
}

My hunch is the problem is due to the microsecond sleep functions I’m using on Linux/Windows. It’s at the mercy of the scheduler when the OmniThing process will continue execution. I’ll experiment tonight with trying to use busywaits instead for the DhtReader. Hopefully that will solve the problem.

I had another question about how OmniThing manages sensor input. I added an SW-420 vibration sensor to my PI Zero and set it up in config.json like this:

    {
        "triggers": [
            {
                "interval": 15000,
                "offset": 1000,
                "command": "poll"
            }
        ],
        "subscriptions": [],
        "type": "MotionSensor",
        "name": "generator_running",
        "input": {
            "type": "DigitalInputPinRaspberryPi",
            "pin": 6,
            "invert": false,
            "pinMode": "Normal"
        },
        "invert": true,
        "constantPoll": true
    }

It triggers properly, but ST then gets a flood of active/inactive messages for the duration of the vibration/motion. Is there any way to configure the monitoring such that it will trigger and then go into a “hold down” state where it won’t trigger until a defined window passes? In my particular case, I’m monitoring that my generator starts - I would like to know immediately (which I think requires constantPoll), but I don’t want to generate tons of messages/alerts once the first trigger occurs.

thanks!
Dave

Hi Dave,

There is no functionality with the current release to achieve that, but I can add it pretty easily. I’ll try adding that tonight and if that goes well continue looking into the DHT reliability issues on raspberry pi.

1 Like

Hoping someone can help me out. Sorry to ask a dumb question but installed OmniThing and wondering what’s next? What do I do/can I do with OnniThing? What’s the benefit?