I've had to stop the development of the Sensor due to other, more urgent, stuff. Some days ago, anyway, I've took it again, because finally the PCB arrived.
Unfortunately, the problem with the temporary suspend, then send a touch for all the buttons and suddenly stop working is still there. I've asked for some help in the Adafruit forum, and they suggested to change the speed of the communication between the board and the sensor.
So, given that I can change the I2C speed down to 100KHz (but the standart speed is 1000kHz), at which speed works the connection with the hub? I've seen that for the SmartThingsWiFiNINA
the speed is set to transmitInterval = 500. Should this value be lower/higher/equal then the I2C speed? And, this are milliseconds or what?
The transmitInterval parameter is used to prevent the microcontroller from flooding the Hub with Ethernet packets. It has nothing to do with the I2C speed. I would not recommend changing the transmitInterval parameter much lower. Instead, your code for the touch sensor needs to handle 'debouncing' the input signal to only send data to the hub when things have settled down, and you know definitively what the user has done.
Also, transmitInterval parameter is in milliseconds, IIRC. ST_Anything will queue up multiple updates and then transmit them all, once 500ms has elapsed since the last transmission window opened.
Ok. The MPR121 has already built in a form of debouncing, from what I've read in the documentation. Anyway, I'll try with different values for the I2C, in the hope that it will solve the problem.
I'll also not mess with the transmitInterval, given that it's totally unrelated to the problem I have.
Does anyone know if there is a known reason for arduino to stop suddenly working.
I have over 15 Hubduino child servos to control my blinds and all of a sudden one of them is not working. I can ping it over lan but telnet to port 8090 is not working. If I cut power from arduino and put it back on -> then it answers to ping but also 8090 port is up until few hours goes by and port 8090 stops working.
Is this a sign of a broken arduino board and is there a fix that I could try?
It sure sounds like that one microcontroller may be having an issue. The first thing to consider swapping out is the power supply for that microcontroller. Perhaps it has started to fail?
Are you using genuine Arduino boards? Or an ESP8266/ESP32 type of board? I would personally just swap out the suspected bad board for another and see if the issue is resolved. You should be able to reuse the existing HubDuino Parent device, even if you change the microcontroller, as long as you use the exact same sketch (with the same IP address) for the new microcontroller board.
Hi @ogiewon . I'm using these: " [LOLIN D1 mini Pro V2.0.0 - WIFI IOT development board based ESP8266 16MB external antenna MicroPython Nodemcu Arduino Compatible] "
I tried to change power supply but there was something weird going on. I got board back online but commands did not go through anymore. Telnet and ping were successful. I changed old double port usb outlet back on and got board online and command worked too. I'm now logging parent and child to see if there is something that is going to help. Issue should happen in couple of hours again..
I have a spare board and I could try that when issue occurs again. By the way could power supply really cause issues which are shown as port not listening? I know anything can be possible but I was just thinking that could bad power supply do that.
I did install new board by using same sketch and ip-address/port but for some reason board created contact and motion child devices. I removed old instance of servo 1 and servo 2 and tried to change child type from contact and motion to servo. That did not help. Port is open and board is connected to wifi. It has right ip address too. For some reason it does not operate as a servo board now. Any ideas what to try?
EDIT: pardon me. I was using wrong sketch and after I found the right one -> everything works as expected. I will still test board which loses 8090 port. Funny thing is... these issues started same time as I installed one Hue lamp to same outlet where arduino power supply is. It can't be the reason for board to lose port 8090 but if power supply can somehow cause port issues to arduino.. then I guess Hue lamp could cause issues to power especially if it's connected to same outlet.
The Hue lamp is a Zigbee device that operates at 2.4GHz. If your Hue Zigbee network is using a Zigbee channel that conflicts with your current 2.4GHz WiFi channel, than that might explain what you've seen. Assuming your Hue lights are attached to a Hue bridge, the bridge will use channel 15, 20, or 25 (IIRC). If you also have a Hubitat Zigbee network, then you should choose a channel for it that does not conflict with your Hue Zigbee network. I would try to run the Hubitat Hub Zigbee network on channels 15 or 20, as channels 25+26 can have issues with some older Zigbee devices. For your WiFi network, make sure that your 2.4GHz network is set to only use WiFi channels 1, 6, and/or 11, at 20MHz channel width.
Here is a visual chart of how Zigbee and 2.4GHz WiFi overlap. I run my Hue Zigbee network on channel 25, my Hubitat Zigbee network on channel 20, and my 2.4 GHz WiFi access points on channels 1, 6, and 11. This has worked without any issues for years.
Yep, I have been dealing with 2,4ghz interference earlier and I'm trying to minimize use of that frequency. Only Hue and few devices (for example arduinos) use that and all other are behind z wave or 5ghz wifi. It could be that certain device could be messed up if channels are overlapping. That been said as I'm using combination of Google Wifi, Hue bridges and Ikea bulbs. Hue channel can't be easily changed because of Ikea bulbs and Google wifi does not allow channel changing at all... so smart home environment here is sort of a compromise of...well all these smart stuff and systems that I have..
I noticed that original arduino stopped working again and now I changed new board. It's been running few hours now and everything seems to work normally. I have to wait and see how does it look at morning. If it's up and running then I'm happy. It was a good decision to buy spare boards when I started with my blinds project
Ok so morning I noticed that board did not work and this is the new board I'm talking about.
Log says:
Same "connection refused" log lines as with the different board before.
Tried to telnet 8090 and it was listening. Then tested to open and close servo again from Hubitat and it started to work. So basically I have same issue with new board but this time board came back alive for some reason. I can't figure anything else than power issue. Next I'm going to unplug devices behind same outlet and see if that helps.
Nope. Because of that possibility I installed new board with new ip address too. All static addresses in my network are not overlapping with dhcp so I think this part should be good.
Moved hue lamp's outlet to a different place and board has been working normally since. Hue lamp is still right there where I installed it but just changed outlet's location. Weird thing if it was because of that. Could it be that Hue lamp causes electricity issues to board when connected to same outlet power strip.
That is a strange one, for sure. I have no hypothesis for how the Hue lamp being plugged into the same outlet as the ESP8266 microcontroller would cause such an issue. Glad to hear you've found a workaround, at least.
I mean I had a lot of problems at the beginning with blinds. For example I plugged servo and board to 2port usb outlet which was connected to power strip. Power strip had its own usb ports too and me and my kids charged phones from there. Couple of minutes later servo started to open and close for no reason. After I unplugged mobile phone from usb port problem stopped.
I thought I was crazy but same thing happened with all my blinds. I had a usb powered cameras too connected to same power strip with blinds but own usb port of course. Blinds were mostly unreachable and they opened and closed like crazy.
That's why I'm wondering if this could be same thing. Maybe something to do with ground voltage potential depending what devices are connected?
when you plugged another device in, it lowered the amperage to the other USB outlet, so the servo probably didn't know how to handle it and started to reset or do random things
@ogiewon as you've seen in my other thread, I've returned to hubduino for my next few projects, one being a dog Feeder (switches, relays and servo) and likely my irrigation as well I'd say (relays most likely).
Its been some time since I looked at this, but it seems quite easy to modify your examples to include custom arrangement of sensors etc and for me I prefer this implementation over tasmota on my wemos mini and nodemcu for a few reasons.
I am still using 1.1.5, as that is what I used for my servo blinds project with 3 servos.
Is there much use for to update to 1.1.7? If so, it's the arduino ide libraries only that need updating? So it won't break my existing blind control? I'm reluctant to update as it works how it is.
I don't mind having to put Mac address or number of buttons so updating just for that I can't justify. Am I losing much else? My blinds have been very stable.
I have always been a fan of the “If it ain’t broke, don’t fix it” saying. So it really is your call. I can’t recall all of the other little tweaks that may have been done since the 1.1.7 release. Nothing major, or I would have done a formal release.
do you have an existing dog feeder? or are you creating one from scratch? if you like, i have a separate base i can ship to you if you'd like. i don't have the food holder or the tray though, i just have the base that contains all the motors inside
I have one already thanks. It was my first esp8266 project a number of years ago. Built from the ground up and stores like 20kg of food.
However it was using arduino ide code and blynk integration.. And had been packed up for 3 years as I didn't have a dog. It's now been brought back to life. Using hubduino code and hubitat rules now.
