bigDvette

If you go to inovelli.com there is only one version of white(matter) dimmer switch. If you have eisy I would try the red version that is zwave if you want to put in to your automation.

Sorry, I am not using these with ISY. They do have zwave versions of these switches I have not tried as. I get no flickering with these switches.

I haven’t seen anything on zwave. It is definitely only dimmers and KPL dimmers. On/off no problem. I can also see the leds in the kpl lighly flicker. My belief is the triac based dimmers are sensitive to some noise and are susceptible to phase changes. The pw3 must be generating noise in to the ac current but my ups and my monitoring don’t show voltage drops so maybe it’s here is some phase inversion when charging? If I set battery back to make it not charge it stops flickering. So the inverter kicking on and off must be causing the issues. I’ve left Insteon in 1 room so if Tesla ever comes out we can look at the problem.

Not for me. I took apart every light switch box in my house and changed to inovelli matter switches. As I went I tested every circuit and did find a neutral load wire that must be grounded somewhere. I removed it and checked everything and still get flickering. the new switches do not blink. I have left my KPLs in the loop for now to give all my leak sensors a dual channel path and to do some scene controlling but mine are hooked to a load. I am going to leave 1 room Insteon only for when Tesla come out. I tried the little devices you wore between neutral and load to reduce flicker but I’m wondering if I should have tried working in front of the switch. I’m still playing with options to remove flickering. My communication and errors have calmed down once I moved the ppm to the furthest location electrically from the powerwall3.

I didn’t go zwave, I’m going to hop over to matter and thread and go all in home assistant on lighting control and deal with all the ugly new tech issues in favor of future development potential . I’ve been happy with Insteon and isy for 20 years but running dual plugins to get apple home devices … has been a lot of work so moving programs to HA. Already have stuff I like better with what I have had with Insteon, but finding ways around them until matter binding is implemented.

Where is this setting? I don’t think I see that setting in the Tesla 1 app.

I started ripping out my 40 or so Insteon dimmers and putting in inovelli matter dimmers. no flicker. It isn’t Insteon’s fault as I’ve had some of these since 2004 with no problems but writing on wall with Insteon so make the change now is my decision.

Tesla says they can come look at it at the earliest date of March 31. What a joke. Told them they are on notice for damage and so far I have a failed soft start AC unit, a few automation devices. I know for sure it only happens when batteries are in this charging / not-charging loop trying to get to reserve. Ive had to set batteries below 100% as they never seem to get to 100%. when neither battery is in this charge / non-charge loop there is no flickering.

I would appreciate any help or advice you have. I’m convinced it is made worse by having backup at 100%. When backup at 100% the charging / not charging graph looks like left side of the picture attached. At 98% it doesn’t do the same thing and looks like left. Essentially I don’t ever see my batteries get to 100% and the constant switching on and off charger creates some of flickering and noise.

I've also seen that it is worse when lightly loaded. At moment mine are in background mode only so always lightly used. The flickers seem to happen when it shows it is lightly discharging and then recharging. I don't know why it needs to do this 2 times a minute, but whatever. Anyway, when it does a calibration and goes totally battery so all load on the batteries the flickering completely stops. It's really annoying, I have like 15-keypadlincs and 35-2477D dimmers. All of them with loads attached flicker occasionally. I've divided my problem in 2 parts. 1) Communication reliability - this doesn't seem too bad but I'm convinced my micro on-off problem is related to the batteries as only the v.43 versions have the problem and all of them have the problem. The .48 versions do not. My PLM is being a little flaky so going to try a brand new one that some people say has better / stronger signal and see what happens. 2) Light flicker. I know these are triac dimmers. The LED bulbs in the Switchlink ON/OFF don't flicker and neither do the insteon bulbs or the lamplinc, so assuming maybe it is the forward phase dimming of the triac. I found a known forward phase dimming bulb I'm going to test and see if it makes any difference. If the flickering can go away, I can maybe solve the comm issues.

I have exactly all of these issues you have. I can confirm that turning off the batteries eliminated the problems. I bought those little blue/yellow dimmer fixers Insteon sells and that didn’t help. I swapped bulbs and that didn’t help. i’ve seen haywire red flashing on the devices a few times. i removed my Transient voltage surge suppressor as a test and that didn’t fix it. while I knew it was doing some flickering I removed the dimmer switch and wired the light direct (no switch) and problem stops. I’ve seen the little leds in the dimmer switch twinkle. Putting on a large load like a hair dryer doesn’t make it do anything. i downloaded the Tesla One app and paired to my PW3s to see realtime voltage and hz. It doesn’t fluctuate much and doesn’t look strange. i think it is happening as it switches to charging the battery. It does this constantly, it doesn’t charge and then stop, it switches between charging and not charging constantly. it’s kinda pissing me off. I assume it must be noise which I can’t reliably diagnose. i have 2 Powerwall gateways connected to a single meter. If in turn off the pw3 on one gateway it still flickers in both houses so the noise or whatever is transmitting upstream of the gateway as well. I’m wondering if it’s the gateway/ I know AC doesn’t care what is line 1 or 2 but can power going out line 1 and coming back as line 2 cause issues. I don’t understand how the gateway is switching internally or if all power goes to the backup side circuits on pw3 and feeds loads from there. anyway, you aren’t alone. Tesla hasn’t been much help and they installed my system.

You can also add it manually. Just add the device by typing https://IP_ADDRESS:8080/desc in the window that pops up. It adds it locally. If it ever finds it on the network you will see it as eisy.local. I have 1 Mac I can't get to find it automatically. I know it is the network setting to allow local access. There is process to reset all of that I just haven't messed with yet.

I keep seeing red blinks on some switches when locally pressed. I've had the issue with device being randomly turned off and now I've had 2 times where all the devices came on (like if you do on with the my lighting scene). Then last night no device presses would work on switches but I could control them from ISY. Looked and all the links in the PLM were gone. I don't think I accidentally held in the button when plugging in. Restored it fine and then all lights came on at 4am. Sound like a failing PLM?

thanks I have done that. It isn't at a specific time. I'm having home assistant monitor the wifi bulb and send me a notice when it goes offline so I can find a time, but there isn't any specific time. It is strange it is only the v.43 modules. They are a pain to replace. I can write an automation in Home Assistant to turn back on the micro modules when light goes unavailable, but that is a hack. I'm wondering if some electrical noise is causing them to turn off at the switch. Like I say, when I see the light bulb become unavailable, if I look at ISY it still says it is On until I query and then it shows off so I don't think Eisy is getting a message to log.

For about the last month my micro on/off switches will randomly turn themselves off. I don't have any programs that use them. I have restored their links to see if that was the problem. The only on/off modules that have this problem are the v.43. These switches are left continuously on since I went to wifi bulbs in those outdoor floods a year ago, but this problem has only recently started. Has anyone else had strange behavior with micro on/off switches? I don't get any off event in the log and the status of the light doesn't update until my query all program runs at 5am. I can see that this particular day the bulbs lost power at 2:33am. I'll wakeup and the lifx devices are offline and these on/off being off is the problem.

I too am using the devlist.yml without problem. you don't have to put it in the nodeserver directory, you can just put it in the directory you login to (home director) and then put in a config var. key = devlist value=/home/admin/{filename}. There are a lot of exception messages all the time getting bulb color and stuff, but seems to work. Home Assistant isn't any more performant ( i have it setup there too) as it also has to poll.

Just out of curiosity after you deleted and added node servers and such, donations a refresh on the mobile app and have it clean up the devices?

Just installed and discovery went fine. All statuses were updated on initial creation of nodes. Didn't have to redo any programs. Thanks!

I am getting states on startup. I removed all nodes and started over. If there is way to make the top level prefix configurable as it doesn't require a subscription per device, then I think it work well. My states represent what I see in MQTT explorer with the contact sensor gate not getting values for lock or obstruction so makes sense they are unknown in AC.

Interesting, I am using a mosquitto service on my docker cluster. Now I don't know if you are using it in dry contact mode or in version 1 or 2 mode, My gate is in contact mode and only shows availability and door values. I don't see anything in the json that indicates what mode it is in (for instance dry contact mode does not support a light or lockout. My lockout in AC never changes from Unknown no matter how many times I operate the door even though I do have a lock and it is locked it always shows unlocked. That may be because my garage door is an 8500 and uses v1 protocol.

Those statuses are always there if I disconnect and reconnect MQTT Explorer even before any elements are updated in MQTT. This is the case for all topic / sub-topic items in JRD-Automation top level topic. I can confirm in HA it pulls in the current state in the MQTT device when it subscribes to the Broker as I have status even before any devices have been controlled.

Not sure if anyone else is using manual add, but I can confirm this still works in the release. Cheers.

I don't know if I followed all that but for sure RATGDO allows you to set the topic prefix and you can change the discovery prefix. Mine is homeassistant for discovery as I didn't change it and you use it as well. The topic prefix is something you have to define in HA if you are using the MQTT plugin (UI discovery) with an external MQTT broker. There you define and can only define a single Topic Prefix to listen for. i had a bunch of other devices (weather, raspi stats) all using an external broker with a common prefix. It would seem that RATGO devices and your plugin support same format as tasmota. In my case my topic prefix is JRD-Automation. In HA i set that as the topic prefix and all devices show up under JRD-Automation as devices and their discovery definition are in home assistant. So in this case you have fixed the "broad topic prefix" to ratgdo/ under that are the devices There is no reason you couldn't have actually left the broad prefix at tasmotans/ as long as you setup the device to publish to that topic it doesn't matter if there are other devices in that topic does it? I changed the MQTT_TOPIC_PREFIX in the API.py file and discovery works just fine and only "Sees" the ratgo devices and adds them to the nodeserver. Home assistant for their MQTT plugin only sees a single topic_prefix but you can have all kind of devices under that topic. So in many ways the broad top level topic is arbitrary and is simply the thing that is subscribed to. I don't think I was proposing a subscription per device which is what it sounds like you are thinking the change I requested would require. So for clarity, I'm using the current plugin, changed it to use my existing top level prefix and it seems to see, find and report status for all the ratgo devices in that topic just as if that top level prefix had been what you had fixed at ratgdons/. Now one thing the plugin doesn't do is get current state when the plugin starts up and simply shows unknown for door state, obstruction and lockout . After the doo is operated it sees the state changes and updates, but obstruction stays unknown because nothing has triggered a change. You can see all states are set in the MQTT device data but the plugin still shows unknown in AC. So I don't think you need to support multiple subscriptions unless people want you to talk to multiple brokers and then you can just install the plugin more than once. As such (since I can see this is working), all that is needed is an ability to override the default top level prefix unless I am really missing something it would seem to be trivial, but as I said I didn't follow all of your response because some of it seemed to not make sense with what I see happening in the plugin already. Happy to beta test any work on this plugin. I have 3 RATGDO devices working with HA and in ISY now.

I was able to set this to my custom topic prefix by changing the value in ratgoapi.py. I have a lot of sensor going to a custom topic prefix I use in Home Assistant so would really like ability to use my open topic prefix via a config key:value. After changing it, I am able to get the status and issue commands. Thanks for your work

all good, happy holidays.