Jump to content

bigDvette

Members
  • Posts

    230
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

bigDvette's Achievements

Advanced

Advanced (5/6)

21

Reputation

3

Community Answers

  1. 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.
  2. 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?
  3. Just installed and discovery went fine. All statuses were updated on initial creation of nodes. Didn't have to redo any programs. Thanks!
  4. 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.
  5. 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.
  6. 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.
  7. Not sure if anyone else is using manual add, but I can confirm this still works in the release. Cheers.
  8. 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.
  9. 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
  10. Yes I refreshed the store. Both the store and the purchased page when click in to Harmony show 3.0.8 and no upgrade message on dashboard and no upgrade button on purchased tab.
  11. I haven't seen it hit the store. Still shows 3.0.8 version.
  12. It looks like the changes are applied in git and version 3.0.9 assigned. Curious if it will be pushed to store soon?
  13. @Flex the updated node server is in the store. If you go to purchases then click reinstall you will see there is an update. I also added a mute status (thought might be handy for what you were doing). I’m not 100% that status will get added to existing speakers. The speakers should get the same names if they get re-added so if you have any problems try deleting the Sonos speakers and then restart the nodeserver. I usually remove them using the nodes tab on the polyglot web page. if you change play, pause, volume or mute from say the Sonos app, it will take up to as many seconds as you have configured the shortpoll on the config tab of the nodeserver.
×
×
  • Create New...