Announcement

Collapse
No announcement yet.

Remote RaspberryIO Connects, But No Remote Plugin on Manager

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Remote RaspberryIO Connects, But No Remote Plugin on Manager

    I have followed the steps in configuring remote RaspberryIO between a RPi 3 and a Windows HS3 system using RaspberryIO ver 3.0.0.12. The plugin on RPi shows connection to the HS3 system and the INFO lines. The Windows HS3 system shows the plugin connected, and if I disconnect on the RPi, I see it disconnect on HS3, then reconnect when I run it on the RPi again. I rebooted the RPi a few times and ran apt-get update/upgrade once more for good measure then rebooted again.

    I'm NOT seeing the Remote Plugin on the Manage Plug-Ins screen, and under Plug-ins | RaspberryIO, I see Config, User Guide, and Forum, but no instance-specific option. Instance name is set in the RPi config file per your instructions.

    I've set Log Level to debug on the RaspberryIO Plug-in on HS3, and see the plugin RaspberryIO has connected and I see "IP:<shows correct RPi IP>:53874", and the same INFO lines I see in the console of the RPi. I also see a log entry when I start the RaspberryIO plug-in on the Windows system that says "ERROR System is not a Raspberry Pi" before all the non-error connection log entries for the RPi, but I presume that is just saying you can't run RaspberryIO plugin natively on the Windows PC since it's not the expected platform/architecture.

    My systems have all the outward signs of the two talking to each other, except for the Remote Plug-in is missing from the Manage Plug-ins, and there is no instance-specific configuration screen under the Plugin config menu.

    I installed the RPi Debian from scratch yesterday, and all apt-get updates/upgrades are applied. The platform is a RasPi 3 Model B, Debian 9.4, and Mono 4.6.2 (with all mono parts you describe in your upgrade to 4.x post). On both the RPi and Windows 10 1709 with HS3 3.0.0.368, I've got RaspberryIO plug-in ver 3.0.0.12.

    Does this sound like a familiar issue? What am I doing wrong?
    Last edited by dzee; April 1st, 2018, 11:37 AM.

  • #2
    You mustn't start the RaspberryIO plugin on your Windows system

    Start the remote instance on your RPi, then post what you get in the HS3 logs and in the linux console of your RPi.

    Comment


    • #3
      Found the problem

      I just found the problem. It was me not checking my run.sh file carefully enough.

      After looking at it a few times, I realized I had accidentally put a duplicate "=" on the instance name parameter, so the line read instance==<instance-name>. Effectively, it was not getting an instance name.

      I now see the Remote Plug-ins with the instance name and correct IP, and ONLY the "config-<instance name>" on the RaspberryIO plugins menu.

      Thanks also for the tip about NOT starting the RaspberryIO plugin on the HS3 host. I didn't realize it would run with only the RPi active.

      I'm off to test this afternoon.

      Thanks for the fast feedback, Spud.

      Comment


      • #4
        Raspi-IO is now installed in garage location and it's way more solid than the Insteon garage door sensor/opener modules. Funny, those never failed to open/close the garage doors, just not reliable for the dry contact status. I'm going to make same RasPi a control for irrigation rain cutout, and also sense refrigerator power outage in garage.

        Sent from my SAMSUNG-SM-N910A using Tapatalk

        Comment


        • #5
          Originally posted by dzee View Post
          Raspi-IO is now installed in garage location and it's way more solid than the Insteon garage door sensor/opener modules. Funny, those never failed to open/close the garage doors, just not reliable for the dry contact status. I'm going to make same RasPi a control for irrigation rain cutout, and also sense refrigerator power outage in garage.

          Sent from my SAMSUNG-SM-N910A using Tapatalk
          thanks for the feedback!

          Comment


          • #6
            Originally posted by spud View Post
            You mustn't start the RaspberryIO plugin on your Windows system

            Start the remote instance on your RPi, then post what you get in the HS3 logs and in the linux console of your RPi.
            If you're not using any GPIOs on the RPi that's running HS3 can you leave the plugin off as well?

            I'd still like to use some I/O boards on the RPi that communicate using I2C. This allows for more I/O ports, RGB LEDs, small 2x16 or 4x20 character displays and A2D converters so you can read sensors. It would be nice to have a way to access these as well. In most cases these have Python APIs front ending them so no direct GPIO access is needed, just a way to send & receive to them from HS.
            HomeSeer Version: HS3 Standard Edition 3.0.0.531 | Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
            Linux version: Linux auto 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
            IP Address: 10.0.2.16 | Number of Devices: 417 | Number of Events: 667 | Available Threads: 399 | HSTouch Enabled: True

            Enabled Plug-Ins: AirplaySpeak: 3.0.0.13 | BLBackup: 2.0.61.0 | EasyTrigger: 3.0.0.65 | LiftMaster MyQ: 1.3.7006.42100
            mcsMQTT: 4.0.2.2 | PHLocation2: 3.0.0.53 | Pushover 3P: 0.0.0.45 | Z-Wave: 3.0.1.262

            Z-Net version: 1.0.23 using a HomeSeer SmartStick+: 6.04 (ZDK 6.81.3)

            Comment


            • #7
              Originally posted by Timon View Post
              If you're not using any GPIOs on the RPi that's running HS3 can you leave the plugin off as well?
              yes

              Originally posted by Timon View Post
              I'd still like to use some I/O boards on the RPi that communicate using I2C. This allows for more I/O ports, RGB LEDs, small 2x16 or 4x20 character displays and A2D converters so you can read sensors. It would be nice to have a way to access these as well. In most cases these have Python APIs front ending them so no direct GPIO access is needed, just a way to send & receive to them from HS.
              well, there is a lot of different I/O boards for RPi, integrating them in the plugin would mean to add some different code for each one, not ideal...

              Comment


              • #8
                Originally posted by spud View Post
                well, there is a lot of different I/O boards for RPi, integrating them in the plugin would mean to add some different code for each one, not ideal...
                I know and I've been think about that.

                There is no way you would want to do the actual I2C or other protocols but let the existing drivers written by the supplier do it most of these are written in either shell script or python.My idea would be a general interface protocol for doing strings reads/writes, integer reads/writes and bit reads/writes. So all you have to do is the basic transport then let the user write the final shell script that interfaces between you and the device driver

                All shell scripts would follow a fixed set of rules and be named in a consistent way similar the way plugins are named. They would also return data in a consistent manner. So once the protocol is written the rest is up to the script to get and receive that data from the hardware.

                Bit data would look exactly as it does now, integer data, such as to and from an A2D or D2A would be much like a dimmer. And string data would be kinda like sending PushOver or Mail messages.

                It would be good to write a couple of interface scripts for Adafruit and Pimoroni must useful devices. I'd be willing to write the script for Pimoroni Automation pHAT and the Adafruit i2c / SPI character LCD backpack which can control the 16x2 and 20x4 displays.

                Actually this wouldn't have to be just for the Pie, it could be a way to interface lots of things between HS3 and Unix like system that supports mono on any platform.

                This needs some more fleshing out but I don't think there isn't much too it since it's the user supplied script that is responsible to actually get the data to the device. I'd be more than happy to be a sounding board working on the basic protocol if you thing this would be useful.

                Just my musing on the subject.
                HomeSeer Version: HS3 Standard Edition 3.0.0.531 | Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
                Linux version: Linux auto 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                IP Address: 10.0.2.16 | Number of Devices: 417 | Number of Events: 667 | Available Threads: 399 | HSTouch Enabled: True

                Enabled Plug-Ins: AirplaySpeak: 3.0.0.13 | BLBackup: 2.0.61.0 | EasyTrigger: 3.0.0.65 | LiftMaster MyQ: 1.3.7006.42100
                mcsMQTT: 4.0.2.2 | PHLocation2: 3.0.0.53 | Pushover 3P: 0.0.0.45 | Z-Wave: 3.0.1.262

                Z-Net version: 1.0.23 using a HomeSeer SmartStick+: 6.04 (ZDK 6.81.3)

                Comment

                Working...
                X