giomania

Same here. Sent from my iPhone using Tapatalk Pro

Same for me. Alexa said the skill was not enabled. Sent from my iPhone using Tapatalk Pro

There are separate instructions for installing and initializing the SSD and for installing for HA in a VM, so it seems like it would be the same script to install HA, but we would need an expert to chime in. Mark

I saw this blog post about configuring the eisy to boot from an NVMe SSD, and it clearly states the process will wipe out any VMs installed. I just installed Home Assistant a few weeks ago on the NVMe SSD, and don't really want to lose it. That said, I would like to use the SSD for the extra performance benefits noted in the blog post. Will the migration without the loss of installed VMs be supported in the future? Thank you. https://developer.isy.io/blog/Supercharged

I am still stuck on 5.6.2 and unable to upgrade. Were we expecting this release to fix this type of issue?

I also cannot update to 5.6.3, nor PG3x v3.1.36 before that. I have been trying with PG3x v3.1.36 since it was released mid-july. Multiple package installations and reboots. Hopefully this is part of the issue Michel discovered. Mark

Update on what I learned from UDI support. MQTT is installed, however PG3 and PG3x make use of a private MQTT broker for internal communication between the various components, and that package is specifically configured to support PG3x. They advised I should just use another mqtt broker on another device on my network, so I used a broker on my Raspberry Pi that is for a different project, but is now serving two purposes. I hope this helps.

So the commands no longer work to install mosquitto I think they have locked down the eisy more. I am going to start a ticket.

Oh darn. I guess I forgot that I probably did that back in the day. Let me do this and report back. Thank you.

I use 1884 because I have another MQTT broker on my HTPC that only controls the fans in my theater for 4D Wind tracks added to movies. It is long story, lol

The MQTT node server is the broker. Those logs only show polling, unless I restart the node server. I restarted it and then downloaded the log, attached. I don't notice anything out of the ordinary. MQTT_4-6-2023_22820-PM.zip

I mentioned this could be an issue earlier, but in case it was missed, let me ask a direct question: Is there any reason why a reserved IP address that is outside the DHCP range will not connect? Like because there is probably no DNS defined because it is outside the DHCP range set in the router? Thanks. Mark

Yeah, the clients still won't connect.

Yes, the external IP address is 10.10.2.20. I just had that in there earlier, and the result was the same. I will add it again, and restart PG3x, but I don't think that will fix the issue.

Here is the MQTT config:

Here are the relevant settings for the eisy: The eisy is at 10.10.2.20 I used to have a static IP on the Polisy, but as you pointed out, that is no longer possible on the eisy, so I set the reservation in the router (UDM Dream Machine Pro), and everything connects fine and works except for MQTT. I do have multiple LANS, and cross traffic is allowed. It seems like I have two options: 1) Change the reserved IP to inside the DHCP range. This requires changing many MQTT client devices and a remote program that executes scenes via the ISY through HTTP Get. 2) Change the eisy to a static IP address. I ran my ISY 994ir/Pro and Polisy for years in this fashion without a single support ticket lodged due to this configuration. Any more insight before I decide? Thanks. Mark

Yes, I do have DHCP enabled and set a DHCP Reservation in the router. I have restarted both PG3x and the admin console. I have checked the configuration tab of the node server. This is the basic problem: I think I realized the issue: My static IP address is outside the DHCP range, as would be expected, but any reserved IP address would need to be within the DHCP range. So I need to decide how I want to handle this going forward. I will post again with what I decide to do and confirm this is resolved. Thanks. Mark

The node server is on-line and connected to the EISY, but there is no actual communication between the node server and the ISY, because I can manually switch a device on via the button or its web UI, and the ISY status never updates. So I looked in the console of the Tasmota device, and it is not connecting. The only change between the Polisy and EISY is that UDI no longer allows use of static IP addresses, so I had to set a reservation in my router. This must be what is preventing the communication. Any solutions to this from the node server side?

Hello, I installed my eisy today and the MQTT Node Server is not working on PG3x v3.1.24. I restarted the NS per the migration instructions. Any ideas what could be wrong? Thank you. Mark

I determined why the nodes were not added. It was because I have another smart plug with the ID: "HT_Fans", as well as this 4-channel relay with the ID: "HTFans". I noticed in the node server log that the underscore was removed from the smart plug, apparently (I might be wrong there, lol). Anyway, I changed the 4-channel relay ID to: "4DFans", and it was successfully added. That said, I still cannot control it, so I suspect there is an issue with the commands controlling the power to each relay. I can switch the relays on or off in the device, and the status change is reflected in the Admin Console, but the commands for each relay do not work, presumably because it is configured as a switch, not a multi-channel switch. When I use the "powerx" commands (with x corresponding to each relay number) in the device console , the individual relays (1-4) power on or off, so I know the commands work in the device, but not through MQTT. Also, the node only appears as one device in the Node Server, because (again, presumably) it is configured as a switch, vice a multi-channel switch. If I were able to use multiple MQTT topics to define each relay as a separate topic, I think it would work. But apparently, that is not possible with Tasmota. Mark

My apologies, I should have specified multi-channel power devices. Your example uses 1 TempHumid and 1 switch, so I am not sure if that would work for my situation. It is a four-channel power relay with NO and NC terminals: https://www.athom.tech/blank-1/4ch-inching-self-lock-relay I did research and MQTT can address multiple power devices by using Power1, Power2, etc., so that is what I have been attempting to do, but it is not working. This is what is in the devfile, but the nodes are not added. Perhaps the syntax is not correct? {"id": "HTFans", "type": "switch", "status_topic": "stat/HTFans/POWER1", "cmd_topic": "cmnd/HTFans/Power1"}, {"id": "HTFans", "type": "switch", "status_topic": "stat/HTFans/POWER2", "cmd_topic": "cmnd/HTFans/Power2"}, {"id": "HTFans", "type": "switch", "status_topic": "stat/HTFans/POWER3", "cmd_topic": "cmnd/HTFans/Power3"}, {"id": "HTFans", "type": "switch", "status_topic": "stat/HTFans/POWER4", "cmd_topic": "cmnd/HTFans/Power4"} Thank you.

I was wondering if it is possible to support multi-channel devices? I have an Athom Tasmota 4-channel relay, and multiple topic payloads can be set buy rule to control the various channels, but it believe this node server only supports a single cmd_topic per device? I hope that makes sense. Thank you.

And when can we expect you to focus on the PG3 migration?

That is unfortunate. When they fix the PG3 migration, then I will have to put in a ticket for them to change the IP address via SSH, unless someone can point me to the required commands where I can insert my own syntax for my 10.10.2.x network? Thanks.

Another vote for static IP control via GUI...not only via SSH. For my use case, I have a control system that I use to call my ISY scenes and devices via http get, and I need a static IP address outside of DHCP to support this functionality. If I have to figure out how to change that via SSH, that is going to take me probably a couple of hours, which is unnecessary time I don't need to waste. I am going to sit on the sidelines waiting to deploy my eisy until this issue and the PG3 migration tool is resolved.